of what if the msgb is 'borrowed' or 'owned/transferred'. Whenever we reach a
_send method we actually transfer the ownership (as the data might be queued
or such).
The other technical part is to make sure we first establish a rule by
1.) adding doxygen/API documentation to the sendmsg function
2.) maybe look into introducing dummy annotations like __borrow, __takes that
we could autocheck in the future (e.g. by extending spaze/smack)
The issue with reviewing such a patch is the question if you have catched
everything. E.g. I think you missed need to convert (and what it calls):
static int gprs_ns_tx(struct gprs_nsvc *nsvc, struct msgb *msg)
{
...
default:
LOGP(DNS, LOGL_ERROR, "unsupported NS linklayer %u\n", nsvc->ll);
msgb_free(msg);
ret = -EIO;
break;
}
return ret;
}
> As reported in ticket #55 SGSN can crash due to double free-ing. You
> can replace 'can' by 'will' in that last phrase. I had a sift through
> the code and tried to solve this by removing the free in gprs_ns.c.
> Whenever the calling function created the msgb-struct, I have made the
> function free it after its use. If the function got the msgb from a
> calling function, there will not be a free (hoping that will be done
> on the higher level).
>
> HTH/F
If you need higher bitrates, implementing header and payload compression
at the SNDCP level in the SGSN is possible.
Also, always keep in mind that while you can offer 7 TS with GPRS/EDGE,
almost no phone has support for a multislot class that allows for 7 TS
in DL. So multiple phones can fill the 7 TS, but it's unlikely one
phone can use all of them.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
OpenBSC Startup:
http://pastebin.com/bXEhizAG
moi::states:
http://pastebin.com/9MiRRGP0
In the nano startup - the two things that stand out are the complains
about flag 3 and the NSE:
27855:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: BTS:0 flag 3 not
setting or set!
27855:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: GPRS NSE:0 flag
3 not setting or set!
42142:DBG:GBHSS_STACK:bgp_error_reporter() : PROTO_ERR:
Msg=3DGPRS_BGP_RL_UL_UNITDATA_REQ, Err=3DGPRS_NSEI_NOT_OPERATIONAL
42142:DBG:GBHSS_STACK:bgp_process_msg failed :
msg=3DGPRS_BGP_NM_BVC_RESET_REQ err=3DGPRS_NSEI_NOT_OPERATIONAL
Any thoughts or additional data points I should collect?
Thanks,
Gus
<a href=3D"http://pastebin.com/qLatWdtB" target=3D"_blank">http://pastebin.=
com/qLatWdtB</a><br>
<br>
OpenBSC Startup:<br>
<a href=3D"http://pastebin.com/bXEhizAG" target=3D"_blank">http://pastebin.=
com/bXEhizAG</a><br>
<br>
moi::states:<br>
<a href=3D"http://pastebin.com/9MiRRGP0" target=3D"_blank">http://pastebin.=
com/9MiRRGP0</a><br>
<br>
In the nano startup - the two things that stand out are the complains<br>
about flag 3 and the NSE:<br>
<br>
27855:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: BTS:0 flag 3 not<br>
setting or set!<br>
27855:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: GPRS NSE:0 flag<br>
3 not setting or set!<br>
<br>
42142:DBG:GBHSS_STACK:bgp_error_reporter() : PROTO_ERR:<br>
Msg=3DGPRS_BGP_RL_UL_UNITDATA_REQ, Err=3DGPRS_NSEI_NOT_OPERATIONAL<br>
42142:DBG:GBHSS_STACK:bgp_process_msg failed :<br>
msg=3DGPRS_BGP_NM_BVC_RESET_REQ err=3DGPRS_NSEI_NOT_OPERATIONAL<br>
<br>
Any thoughts or additional data points I should collect?<br>
<br>
Thanks,<br>
<font color=3D"#888888">Gus<br>
<br>
</font></blockquote></div><br>
--00163646d380b12b2004ae744714--
OpenBSC Startup:
http://pastebin.com/bXEhizAG
moi::states:
http://pastebin.com/9MiRRGP0
In the nano startup - the two things that stand out are the complains
about flag 3 and the NSE:
27855:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: BTS:0 flag 3 not
setting or set!
27855:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: GPRS NSE:0 flag
3 not setting or set!
42142:DBG:GBHSS_STACK:bgp_error_reporter() : PROTO_ERR:
Msg=GPRS_BGP_RL_UL_UNITDATA_REQ, Err=GPRS_NSEI_NOT_OPERATIONAL
42142:DBG:GBHSS_STACK:bgp_process_msg failed :
msg=GPRS_BGP_NM_BVC_RESET_REQ err=GPRS_NSEI_NOT_OPERATIONAL
Any thoughts or additional data points I should collect?
Thanks,
Gus
My init.d script does the following in short:
modprobe mISDN_dsp
modprobe mISDN_l1loop nchannel=30 interfaces=2
sleep 1
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 192.168.253.0/24 -o eth0 -j
MASQUERADE
screen -S bsc -d -m su gsm -c "osmo-nitb -d
DRLL:DCC:DMM:DRR:DRSL:DNM:DSMS:DMNSMS:DPAG:DMUX -c /etc/openbsc/openbsc.cfg
-m -P"
screen -S lcr -d -m su gsm -c "/usr/sbin/lcr start"
I'm using mISDN_l1loop.ko from current mISDN git because it was not included
in my kernel. Small patch to make it compile:
--- a/drivers/isdn/mISDN/hwchannel.c
+++ b/drivers/isdn/mISDN/hwchannel.c
@@ -19,6 +19,8 @@
#include <linux/module.h>
#include <linux/mISDNhw.h>
+bool flush_work_sync (struct work_struct *);
+
static void
dchannel_bh(struct work_struct *ws)
{
-- Lennart
--00504502c5d4681bbb04a8fd3d31
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><div class=3D"gmail_quote">2011/7/26 Konrad Meier <span dir=3D"ltr"><=
;<a href=3D"mailto:meierk@informatik.uni-freiburg.de">meierk(a)informatik.uni=
-freiburg.de</a>></span><br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I could solve the above problem by a system restart. The mISDN_l1loop modul=
e was loaded but for some reason could not be used by LCR. The LCR error me=
ssage was:<br>
000000 ERROR loop port 1 failed to bind socket. (errno 93)<br>
<br>
<br>
By playing with the mISDN_l1loop module I discovered a strange problem. If =
I load the module with "modprobe mISDN_l1loop pri=3D1 nchannel=3D30&qu=
ot; all system memory is allocated by LCR after some seconds.<br>
<br>
If I load it with "nchannel=3D20" than everithing works fine.<br>
<br>
Can someone confirm this problem?<br>
<br>
Regards<br><font color=3D"#888888">
Konrad<br></font></blockquote><div><br>From my experience, no.<br>My init.d=
script does the following in short: <br><br>=A0=A0=A0=A0=A0=A0=A0 modprobe=
mISDN_dsp<br>=A0=A0=A0=A0=A0=A0=A0 modprobe mISDN_l1loop nchannel=3D30 int=
erfaces=3D2<br>=A0=A0=A0=A0=A0=A0=A0 sleep 1<br>
<br>=A0=A0=A0=A0=A0=A0=A0 echo 1 > /proc/sys/net/ipv4/ip_forward<br>=A0=
=A0=A0=A0=A0=A0=A0 iptables -t nat -A POSTROUTING -s <a href=3D"http://192.=
168.253.0/24">192.168.253.0/24</a> -o eth0 -j MASQUERADE<br><br>=A0=A0=A0=
=A0=A0=A0=A0 screen -S bsc -d -m su gsm -c "osmo-nitb -d DRLL:DCC:DMM:=
DRR:DRSL:DNM:DSMS:DMNSMS:DPAG:DMUX -c /etc/openbsc/openbsc.cfg -m -P"<=
br>
=A0=A0=A0=A0=A0=A0=A0 screen -S lcr -d -m su gsm -c "/usr/sbin/lcr sta=
rt"<br>=A0<br>I'm using mISDN_l1loop.ko from current mISDN git bec=
ause it was not included in my kernel. Small patch to make it compile:<br><=
br>--- a/drivers/isdn/mISDN/hwchannel.c<br>
+++ b/drivers/isdn/mISDN/hwchannel.c<br>@@ -19,6 +19,8 @@<br>=A0#include &l=
t;linux/module.h><br>=A0#include <linux/mISDNhw.h><br><br>+bool fl=
ush_work_sync (struct work_struct *);<br>+<br>=A0static void<br>=A0dchannel=
_bh(struct work_struct *ws)<br>
=A0{<br><br>-- Lennart<br></div></div>
--00504502c5d4681bbb04a8fd3d31--
systems from the same vendor, as it is assumed that these systems have
seen a priori more testing time and are thus more reliable than any
multi-vendor combination has seen/would be.
Should there be a problem, it is also a lot easier and faster to get
support from a vendor, when he can't first try and blame the other
vendors box, or the translator in between. Here, again, risk
management...
While the lock-in is indeed a bad thing, it is still considered the
lesser evil, compared to the effort needed to do q/a testing in mixed
systems on nation-size scale plus R&D for the translators plus
battling for support with N competing vendors, all blaming each other.
This is the oh-so-familiar argument on why many companies use
exclusively Microsoft, or everything Apple, etc...
Just my 0.05 chf on why translators did not happen... (yet?)
Cheers,
Thomas
--=20
Excercise 17:
If the human brain was simple enough for us to understand we'd be so
simple we couldn't understand.
Prove this by induction.
Sure, it would be a nice addition, but it's not something that I consider
extremely important. With regard to 'near future': I would say that in
something like six months the osmo-bts (BTS-side A-bis) code will have matured,
and is ready for an relaatively painless integration with OpenBTS.
I personally think the USRP hardware cost is still way too high, and I would
rather want to work on something that puts the financial entrance barrier to
private BTS ownership much lower.
Most of the people using OpenBSC today either use it commercially (and can
afford the nanoBTS units), or they use it private and either with a very
cheap second hand nanoBTS, or with a inexpensive BS-11. The recent work
on supporting the RBS2308 that can be found for < 1000 USD goes into the
same direction.
I think whatever hardware will be affordable to hackers will see OpenBSC
support - just as well as any hardware where we have a commercial customer
will get OpenBSC support.
> > This is where I don't get you. All that needs to be removed is the L3-to-SIP
> > bridge. It doesn't make the vast majority of OpenBTS code disappear,
> > and it does not render that latter part useless. A full-blown GSM network with
> > all its components brings a lot of complexity. The stand-alone OpenBTS is
> > much more simple. And why would you want all the complexity if you don't
> > need to interoperate with legacy GSM?
>
> Well, because the the osmocom-integrated version will be, before or
> later, more full-featured than OpenBTS standalone.
>
> Features such as multi-arfcn, handover, maybe GPRS/EDGE will be usable
> only jointly with Osmocom integration but not by the opensource OpenBTS
> standalone version.
If you use the USRP hardware (or any other SDR hardware), you cannot use
GPRS/EDGE whether you use Osmocom + OpenBTS or OpenBTS standalone. As for
hand-over, you may be right, but I don't know the OpenBTS plans here.
Multi-ARFCN: This is an aspect of the radio-modem. So again, on the same
hardware any OpenBTS/OpenBSC integration will not change this.
> Obviously the community will then use the OpenBTS/OpenBSC integration
> that would reach more features than just OpenBTS in the opensource edition.
well, but you loose the important 'simplicity' feature. Right now I doubt
there are that many people in our community who understand OpenBSC and the
GSM/GPRS network architecture enough to deploy a network (like the burning man
or CCC event networks) with it. We have close to zero documentation, and
unless you know GSM protocol details, you are lost. VoIP is much better
understood in the FOSS and Internet community!
> So the integrated code will grow while the "OpenBTS commercial code"
> will leave behind with less features and more buggy code (because less
> used).
you are making assumptions here. Do you have evidence or at least some
other indication that bug fixes are not being propagated from the commercial
to the free version?
> Osmocom and it's possible future changes to the market of GSM
> technologies could be defined as "the WikiLeaks of the GSM Industry" :-)
I think this is a very bad comparison. We do not leak any proprietary/secret
information. We just break the ignorance of the Free Software community to
ever implement any of those openly-specified protocols. Not different from
Free Software entering any other area of technology.
And while we're doing that, we of course also like to challenge the ridiculous
claims of hundred-man-year efforts that allegedly went into some proprietary
GSM protocol stack implementations, which are often claimed by the existing
carrier equipment industry.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
> Meanwhile, Andreas Eversberg has been working on a BTS-side A-bis implementation
> for the OsmocomBB-BTS (idea: using 2 heavily modified phones to run a
> simplistic BTS), and I have started to split that code out into a separate
> repository at http://cgit.osmocom.org/cgit/osmo-bts/
>
> This code should eventually be used with the OpenBTS, and potentially other
> BTS types, too.
That's cool!!!!
>
>> With that approach the 'GSM-um' interface would be a very simplified
>> module of the overall system and osmocom would completely replace
>> OpenBTS all-in-one project.
>
> This is where I don't get you. All that needs to be removed is the L3-to-SIP
> bridge. It doesn't make the vast majority of OpenBTS code disappear,
> and it does not render that latter part useless. A full-blown GSM network with
> all its components brings a lot of complexity. The stand-alone OpenBTS is
> much more simple. And why would you want all the complexity if you don't
> need to interoperate with legacy GSM?
Well, because the the osmocom-integrated version will be, before or
later, more full-featured than OpenBTS standalone.
Features such as multi-arfcn, handover, maybe GPRS/EDGE will be usable
only jointly with Osmocom integration but not by the opensource OpenBTS
standalone version.
Obviously the community will then use the OpenBTS/OpenBSC integration
that would reach more features than just OpenBTS in the opensource edition.
That means that in few times only the "integrated code" will works
better, because it will attract more user and will start getting used in
"production environment".
So the integrated code will grow while the "OpenBTS commercial code"
will leave behind with less features and more buggy code (because less
used).
That's why i just think that the destinity of OpenBTS is to integrate
(directly or just some piece) with OpenBSC, but doing that it will loose
several important value of the "OpenBTS commercial edition" and people
will start using what can be used for free instead of paying.
That's what usually happen within the opensource environment, before or
later.
It could reasonably happen also with that opensource gsm environment.
My comments was just consideration on this to stimulate the
considerations on this by the various project players.
I am just an opensource advocacy troll that like telephony stuff and
perceive very valuable the achievement of the hacking community in
opening a closed technology like GSM.
Osmocom and it's possible future changes to the market of GSM
technologies could be defined as "the WikiLeaks of the GSM Industry" :-)
-naif
p.s. i have no commercial interests of any kind in that stuff
