OpenBSC July 2010

openbsc@lists.osmocom.org

19 participants
48 discussions

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

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

[PATCH 0/1] Add bport0/1 support for bs11_config
by Daniel Willmann 14 Dec '10

14 Dec '10

Hello, second try to add support to bs11_config for bport0/1 configuration. This time with enum abis_bs11_line_cfg. It seems sometimes creating bport1 fails, even LMT shows create obj greyed out. Don't know why yet. Regards, Daniel Willmann Daniel Willmann (1): Add {create,delete}-bport1 and bport0-{star,multidrop} to bs11-config openbsc/include/openbsc/abis_nm.h | 10 +++++++++- openbsc/src/abis_nm.c | 31 +++++++++++++++++++++++++++++-- openbsc/src/bs11_config.c | 26 ++++++++++++++++++++++++++ 3 files changed, 64 insertions(+), 3 deletions(-)

4 5

Wanted: Osmocom logo
by Harald Welte 03 Aug '10

03 Aug '10

Hi! It's about time that we find some kind of graphical project logo for the Osmocom project. Osmocom is intended as an umbrella project for software like OpenBSC, OsmoSGSN, OsmocomBB and others. So it might even be interesting to have some kind of 'family' of logos that all have the same general theme.... At least the bigger projects like OpenBSC and OsmocomBB definitely deserve their own incarnation within that family. If you want to contribute to our project but are not a die-hard C developer, this is your option to contribute! The logo must be under a license that permits use+modification for the Osmocom project itself. Editability for the general public is not important. With regard to formats, I would prefer something as SVG that we can then render into pngs of various sizes whenever there is demand for it. If you have a proposal, simply send it (or a link to a URL) to the openbsc(a)lists.gnumonks.org mailing list. Thanks in advance for any submissions! -- - 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)

11 20

Channel Release Changes to Master
by Holger Freyther 30 Jul '10

30 Jul '10

Hi all, I have merged the Channel Release changes that were prototyped/used in the on-waves/bsc-master branch and basic testing shows that it is working. If you see weird things happening, please tell me and I try to figure out if it is due the changes I made or not. The problem I tried to solve was this: Assume a phone sends a SMS (allocates SAPI=3) and then we do release the channel. Now this can happen with a nanoBTS (and I think it is a bug): BSC BTS/MS RF Channel Release -> <- RF Channel Release Ack <- Release Indication SAPI=0 <- Release Indication SAPI=3 The OpenBSC code used to declare the lchan as available with the RF Channel Release ACK, we also decided to release the channel with the SAPI release indication.. So we were sending a RF Channel Release twice... Now with a loaded cell we could have re-allocated this lchan and then we release someone's else lchan... I was seeing from RF Failures, to BTS crashes with two concurrent phones doing call testing.. Our release procedure now works like this: chan_alloc.c is called to release the lchan. 1.) we remember the release reason and if we should send a SACH deactivate 2.) we declare the channel to be in state release request 3.) we start to release the highest allocated SAPI != 0 (well only three) 4.) from abis_rsl.c we will call to chan_alloc.c in case a SAPI got released and repeat 3rd). 5.) If only SAPI=0 is left we either release or send a SACH deactivate.. 6.) we send a RF Channel Release...

1 0

New cellmgr-ng git repository filled with content
by Holger Hans Peter Freyther 27 Jul '10

27 Jul '10

Hi all, I have just pushed some code to a public repository. It was written to run on an embedded Linux platform and convert from E1/MTP-Level1 to TCP/IP. Besides being hacky (I had to do more than initially planned) it provides some code for MTP-Level3 and handles the link test (SLTM/SLTA). The code is using a library that has only existed for a couple of days and need to be ported to libosmocore, the new vty code and such, it will eventually happen. regards holger

1 0

AW: OpenBSC+LCR+Asterisk: I got it!
by Andreas.Eversberg 26 Jul '10

26 Jul '10

i did not write this howto, also i have no access to change it anyway. > To use in extensions.conf is: > > [btsctrl] > exten => _02X.,1,GotoIf($[${CALLERID(name)} != ""]?4) > exten => _02X.,2,Set(CALLIDORIG=${CALLERID(num)}) > exten => _02X.,3,Set(CALLERID(num)=02${CALLIDORIG}) > exten => _02X.,4,Dial(LCR/GSM/${EXTEN:2},120) > > So can I define a prefix (02) for mobiles and forward the calls to LCR. > > Maybe help someone other having my problem. > I suggest Andreas Everberg to update his HowTo...

1 0

AW: OpenBSC+LCR+Asterisk: I got it!
by Andreas.Eversberg 26 Jul '10

26 Jul '10

hi, what howto do you mean? can you give me the link to it? regards, andreas > To use in extensions.conf is: > > [btsctrl] > exten => _02X.,1,GotoIf($[${CALLERID(name)} != ""]?4) > exten => _02X.,2,Set(CALLIDORIG=${CALLERID(num)}) > exten => _02X.,3,Set(CALLERID(num)=02${CALLIDORIG}) > exten => _02X.,4,Dial(LCR/GSM/${EXTEN:2},120) > > So can I define a prefix (02) for mobiles and forward the calls to LCR. > > Maybe help someone other having my problem. > I suggest Andreas Everberg to update his HowTo...

1 0

Unable to configure a BTS
by Luca Bertoncello 25 Jul '10

25 Jul '10

Hi, again! So, as I said in my last E-Mail, I got a new BTS (DSC1800). Now I have to configure it, so I started ipaccess-find to get his IP and then ipaccess-config to configure it. I get this error: lucabert@Luca:/tmp$ ipaccess-config -u 151/0/0 -o 192.168.1.18 192.168.1.108 ipaccess-config (C) 2009-2010 by Harald Welte and others This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY Trying to connect to ip.access BTS ... Lost some E1 TEI link Lost some E1 TEI link Segmentation fault Can someone say me what is the problem? Thanks! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 23 Fröbelstr. 57, 01159 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de _______________________________________________________________________

5 27

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2010