December 2010 - OpenBSC - lists.osmocom.org

Re: Help with sccp library
by mosbah abdelkader 07 Jul '25

07 Jul '25

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

4 3

Several questions
by jason mercury 06 Dec '12

06 Dec '12

I have some questions: 1) When I start bsc_hack bsc_init.c first establishes OML link and initializes the bts then it establishes RSL link and bts starts broadcasting. However, it takes so much time to start the bts. Instead of this I want to do the following: it establishes OML link at the beginning and only once, then when i want to start broadcasting it establishes just the RSL link and bts will start faster since i don't have to wait for OML link. What should be done for this? 2) If i send one or two word messages from telnet interface it is okay. But if i send a longer message the phone could't receive the end of the message correctly(last words may be incomplete). Did any one encounter with this problem? What is wrong with me? 3) Could I send SMS in which extension of the sender is text not integer. For example, i want to send an information SMS that this is a test network. For this purpose i want to send an SMS from 'OpenBSC'. I set the extension of the first subscriber in database as text and tried to send the SMS but SMS wasn't delivered. What should i do? 4) Can i add SMS externally to SMS table of database? Thanks. Jason

4 3

New utility for drawing protocol ladder diagrams
by Harald Welte 21 Feb '11

21 Feb '11

Hi! With the help of graphviz, I have written a small perl-based tool that allows you to generate ladder diagrams. It can be found at git://git.osmocom.org/gen_ladder.git For your reference, I'm attaching a sample input and output file. The bent/curved arrows are a result of graphviz trying to indicate that the message is between e.g. MS and MSC and 'bypasses' BTS and BSC. I'm still waiting for somebody with more graphviz skills to make this an option. Hope this is useful for some of you... -- - 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)

2 1

Proposed OpenBSC application interface
by Harald Welte 15 Feb '11

15 Feb '11

Hi! Collin Mulliner, Tobias Engel and myself have been meeting yesterday to discuss a generic application interface for OpenBSC. They are both doing security analysis and want to achieve a clean way how an external application can get access to a more or less transparent communication channel to the phone. The purpose of this is to be able to send intentionally malformed packets to the mobile phone GSM stack at various different levels within the stack. As of now, they have both hacked some custom code into openbsc that gets them half way where they want to be - but not quite all the way. The requirements can be summarized as follows: 1) Ability to establish a SDCCH or TCH channel by paging the phone As of now, the 'silent call' feature from the VTY already does this. 2) Ability to send arbitrary layer3 protocol messages to the phone Adding this is relatively easy (use rsl_sendmsg on the lchan from the silent call) 3) Ability to receive responses from the phone, as well as error conditions such as 'readio link failure'. We don't have a solution for this yet, and we also have no clean way to identify what might be a response from the phone to the external app, and what might be a message from the phone to the normal network code in OpenBSC 4) Ability to selectively disable partial protocol handling in OpenBSC. Let's say you want to play with the mobile phone call control implementation. In this case, you want to make sure all CC related messages go from/to the external program and not from the regular OpenBSC network code. So what I've been thinking of as a solution to the problem: * store a bypass_flags bitmask related to the subscriber structure, where we indicate values such as BYPASS_RR, BYPASS_MM, BYPASS_CC, BYPASS_SAPI3. * if we process an incoming message from the MS in gsm0408_rcvmsg(), we check if a bypass flag matching the message is found. If yes, forward the message to the external program * if we want to send a message from our own protocol stack to the MS, we check if a bypass flag matching the message is found. If yes, we drop the message that we were about to send. * any messages received from the application will be forwarded to the MS The application interface protocol will likely have a close resemblance to RSL RLL. We need to exchange the following primitives with the application, like: * ESTABLISH REQUEST -- app requests a channel be established to MS (by IMSI) * ESTABLISH CONFIRM -- network confirms a channel has been established * ESTABLISH INDICATION -- network tells app connection was made by MS * [UNIT] DATA REQUEST -- app requests data to be sent to MS * [UNIT] DATA INDICATION -- network indicates data was received from MS * ERROR INDICATION -- network tells app something went wrong * RELEASE REQUEST -- app asks network to release channel * RELEASE CONFIRM -- net tells app that channel was released (as rqd) * RELEASE INDICATION -- net tells app that channel was released (by MS) The channel_number of RSL (indicating on-air timeslot) doesn't make much sense in this context, of course. The link_identifier on the other hand is great as it allows the app to indicate SDCCH/FACCH or SACCH as well as the SAPI. The actual RSL-like protocol would be encapsulated by UDP and available on a socket of the MSC. What do you think? 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)

3 9

Re: OpenBSC on Solaris (WAS: Re: Notes from the 27C3 network)
by omar.atia＠its.ws 07 Jan '11

07 Jan '11

Dears, Sorry for hijacking the thread , next time I will create new thread ... I will try to bind using IP to avoid using SO_BINDTODEVICE ,and I will google IP_BOUND_IF as well. Another issue is the linux command for vty which is the c function under linux called cfmakeraw which I removed from vty.c cause there is no library under SUN for that command or function to link with. Can you please ensure that this commented line will not affect vty functionality ? Thanks, Omar atia ------Original Message------ From: Holger Hans Peter Freyther Sender: openbsc-bounces(a)lists.gnumonks.org To: openbsc(a)lists.gnumonks.org Subject: OpenBSC on Solaris (WAS: Re: Notes from the 27C3 network) Sent: Dec 31, 2010 11:28 AM On 12/31/2010 12:30 AM, Omar Atia wrote: > Dears ,, please help :: Dear Omar, please do not hijack threads, start a new one instead. > > in ipaccess-find.c , can we use bind instead of setsockopt cause solaries > doesn't have SO_BINDTODEVICE defined in socket.h. For ipaccess-find is sending a broadcast packet, so it is important to select the physical interface it should be send on. For the user it is more convenient to write the interface name then to remember the ip address of this interface. Does Solaris provide another way to bind to a specific interface? What about IP_BOUND_IF? If that is not the case we could consider doing a normal bind and bind to the interface via an ip... z. Sent via BlackBerry® from mtc touch

4 12

RFC: Relicensing OpenBSC under AGPLv3
by Harald Welte 01 Jan '11

01 Jan '11

Hi all! This subject came to my attention again recently: Why not relicense OpenBSC under AGPLv3? Right now we are licensing under GPLv2+ (v2 or any later version). However, if an operator was to make lots of private modifications and then operate it on his own network, there would be no distribution and thus no need for him to release his modified versions of the source code. This may sound a bit strange to those who have been with the project since its early days. But we are reaching production quality now, and we already have the first number of production deployments of the software. Companies like Netzing and On-waves have been FOSS-friendly and funding parts of our development effort. They have no issues with the result being Free Software again. However, there are definitely other companies out there who are less fond of sharing... So thus my idea is to put OpenBSC under AGPLv3. This way whoever uses OpenBSC _in modified form_ to operate a communications network will have to provide the source code to that modified form on a network server at no charge. The only controversial question to me is "your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source". 1) does a gsm network count as computer network? i'd say yes. 2) is using a gsm network 'interacting with it remotely'? I'd also say yes 3) what does 'prominently offer' mean in the context of GSM? We don't want the operator to spam their users with advertisement SMS just to know that they can get the soruce code, after all. Notwithstanding those open questions, such a network operator would always have the option of simply sending back his changes for integration in the official project - and thus he would no longer use a modified version which then means there is no need for the prominent notice / download at all. We can make this very clear in the project documentation, putting further encouragement The actual relicensing should be less problematic than I thought, since AGPLv3 is compatible with GPLv3. So I could re-license all parts that I own copyright on (which should be the majority of the code base anyway) under AGPLv3, while the former GPLv2+ components (like VTY code from zebra, or contributions by other people) then become GPLv3-or-later. Of course I would want to encourage all developers/contributors to also follow the re-licensing. Particularly Holger Freyther, Dieter Spaar, Andreas Eversberg, Jan Luebbe, Sylvain Munaut, Daniel Willmann, Stefan Schmidt. So let's start with a poll: a) Do you think re-licensing to AGPLv3 is a good idea? b) If you have contributed, would you re-license your code under AGPLv3? If we have some kind of concesus in the community, I would approach On-waves whether they would want to do the same for their share of the copyright. As their "modifications" are all part of OpenBSC git repository, they would not be subject to any different conditions than before. Thanks in advance for your feedback, 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)

3 5

Re: OpenBSC on Solaris (WAS: Re: Notes from the 27C3 network)
by Dieter Spaar 31 Dec '10

31 Dec '10

Hello Holger, On Fri, 31 Dec 2010 11:24:41 +0100, "Holger Hans Peter Freyther" <holger(a)freyther.de> wrote: > > If that is set on the socket for the telnet interface it does make a difference. Just in case, Cygwin also misses cfmakeraw(), my private modification for this is the following which is of course the same you quoted from the man page. #if defined(__CYGWIN__) /* Workaround for Cygwin, which is missing cfmakeraw */ /* Pasted from man page */ void cfmakeraw(struct termios *termios_p) { termios_p->c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL|IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO|ECHONL|ICANON|ISIG|IEXTEN); termios_p->c_cflag &= ~(CSIZE|PARENB); termios_p->c_cflag |= CS8; } #endif /* defined(__CYGWIN__) */ Maybe there is a Solaris-specific preprocessor symbol and we can add this function to an appropriate place. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

Notes from the 27C3 network
by Holger Hans Peter Freyther 31 Dec '10

31 Dec '10

Hi all, here are some notes about bsc_hack as it ran on the 27C3. In day0 we discovered a nice SQL injection bug, in day1 we had plenty of segfaults, mostly in the error and time-out paths of the MSC (but also some in the BSC API). These included crashes due clearing the channel and removing the ->lchan from the conn, RLL time out handling in the SMS code and some more. The network ran without segfault (only one crash due my stupidity on a new VTY command) after this. The biggest issue as that SMS got stuck. Code review has found some issues immediately but this didn't fix it. On more code review an issue with the 'subscr_get_channel' was identified. First of all the transaction layer just stopped paging requests, e.g. stopping the paging for someone else's subscr_get_channel, then the Call Control code never called subscr_put_channel when it is done. I have created two band aids for this situation but there is a bigger issue with the code. If somebody has spare time and wants to do some simple changes one can do: 1.) The subscriber layer passes the 'subscr' pointer to the paging layer, it should pass the request to it. 2.) It should be possible to cancel channel requests that were not scheduled yet. 3.) Once we started auth on the channel the 'request' state should be changed too. It is not right now due 1.). 4.) ....

3 3

AW: OpenBSC Digest, Vol 24, Issue 26
by Lud Gidiya 29 Dec '10

29 Dec '10

--- openbsc-request(a)lists.gnumonks.org <openbsc-request(a)lists.gnumonks.org> schrieb am Mo, 27.12.2010: Von: openbsc-request(a)lists.gnumonks.org <openbsc-request(a)lists.gnumonks.org> Betreff: OpenBSC Digest, Vol 24, Issue 26 An: openbsc(a)lists.gnumonks.org Datum: Montag, 27. Dezember, 2010 13:00 Uhr Send OpenBSC mailing list submissions to openbsc(a)lists.gnumonks.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.gnumonks.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request(a)lists.gnumonks.org You can reach the person managing the list at openbsc-owner(a)lists.gnumonks.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. RE: OpenBSC+LCR+Asterisk installation problem (Caleb Pal) ---------------------------------------------------------------------- Message: 1 Date: Sun, 26 Dec 2010 14:41:39 -0800 From: "Caleb Pal" <cleb(a)defcon-3.net> Subject: RE: OpenBSC+LCR+Asterisk installation problem To: "'jason mercury'" <jmercury313(a)gmail.com>, <openbsc(a)lists.gnumonks.org> Message-ID: <004901cba54e$0ffe0950$2ffa1bf0$@net> Content-Type: text/plain; charset="us-ascii" Are you using Asterisk 1.8? If so, you should checkout the asterisk_1_8 branch of LCR. LCR git was down, it is now back up at a slightly different location, git://git.misdn.org/lcr.git/. mISDN and mISDNuser git are also at the new path. HTH, Caleb From: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] On Behalf Of jason mercury Sent: Thursday, December 23, 2010 8:15 AM To: openbsc(a)lists.gnumonks.org Subject: OpenBSC+LCR+Asterisk installation problem Hi, I am trying to install a OpenBSC+LCR+Asterisk system according to the how to send to the mail list by Konrad Meier on Tue Oct 12 18:27:33 2010. During installation of LCR I got following error: make[1]: Entering directory `/home/idb/openbsc/lcr' gcc -DWITH_GSM_BS -I./openbsc/include -I./libosmocore/include -I./openbsc -Wall -DCONFIG_DATA="\"/usr/local/lcr\"" -DSHARE_DATA="\"/usr/local/lcr\"" -DLOG_DIR="\"/usr/local/lcr\"" -DEXTENSION_DATA="\"/usr/local/lcr/extensions\"" -D_GNU_SOURCE -fPIC -c chan_lcr.c -o chan_lcr.po chan_lcr.c: In function 'lcr_indicate': chan_lcr.c:2274: warning: assignment from incompatible pointer type chan_lcr.c:2289: warning: assignment from incompatible pointer type chan_lcr.c:2316: warning: assignment from incompatible pointer type chan_lcr.c:2381: error: dereferencing pointer to incomplete type chan_lcr.c:2382: error: dereferencing pointer to incomplete type chan_lcr.c: In function 'load_module': chan_lcr.c:2818: warning: passing argument 2 of 'ast_register_application2' from incompatible pointer type /usr/include/asterisk/module.h:427: note: expected 'int (*)(struct ast_channel *, void *)' but argument is of type 'int (*)(struct ast_channel *, void *)' make[1]: *** [chan_lcr.po] Error 1 make[1]: Leaving directory `/home/idb/openbsc/lcr' make: *** [all] Error 2 Why is this occur? My ubuntu kernel is 2.6.32-24-generic and i exactly followed the steps. I am attaching that how to again. I also couldn't git check out OpenBSC, LCR , mISDN, mISDNuser and i download them from http://www.linux-call-router.de/download/lcr-1.7/. I want to ask that why i can't git clone. When i try to git clone i take following: git clone git://git.misdn.org/git/lcr.git/ Initialized empty Git repository in /home/idb/op/lcr/.git/ fatal: The remote end hung up unexpectedly If any you have idea please help. Thanks. Jason.

1 0

Open BSC sources...
by Omar Atia 28 Dec '10

28 Dec '10

Dear All, I will introduce myself , It is Omar Atia from Lebanon , 8 years telecom experience , willing to know more about open BSC , how can I get the sources if it is free download them (not through unix), from where could I buy the BTS stations are they available it has been sold out as written on the web site . can we configure OpenBTS with OpenBSC ? is it configurable or not tested yet . I have a lot of questions related to this Area as I want to implement the GSM network for testing purposes only to go deeply into it . Thanks,,, Omar Atia TPSG - Functional Consultant ITS Logo.png T. + (961) 9 641555 ext. 416 M. + (961) 3 001294 F. + (961) 9 641555 ext. 217 degital signeture.pngE. <mailto:omar.atia@its.ws> omar.atia(a)its.ws

1 0