OpenBSC October 2010

openbsc@lists.osmocom.org

16 participants
16 discussions

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

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

Reply:- Need help on Open BSC code.
by tejas oza 14 Dec '10

14 Dec '10

Hi Holger, After trying to checkout and build the OpenBSC using command git checkout -b on-waves/bsc-master origin/bsc-master, we got error as fatal: git checkout: updating paths is incompatible with switching branches. Did you intend to checkout 'origin/bsc-master' which can not be resolved as commit? So, may be we are not correct on the path or something else. can you please advice, as we are not able to find bsc_msc_ip binary file. On Thu, Sep 30, 2010 at 9:50 AM, Holger Hans Peter Freyther < holger(a)freyther.de> wrote: > On 09/30/2010 03:04 PM, tejas oza wrote: > > Hi Guys, > > > > We are implementing the separate MSC module and we will be using the > openBSC, > > and we are mainly concerned for SMS services. So, I will be highly > obliged if > > you can provide us the documentation on openBSC code so that we can > understand > > the messages expected on separate MSC side from open BSC and the messages > to > > be sent from MSC to openBSC side. > > In the on-waves/bsc-master branch you will find a bsc_msc_ip binary that > will > be able to connect to a real MSC through somthing that is coined SCCP-Lite > (SCCP encapsulated inside the ipaccess protocol). > > If you look at bsc_hack it has no connection to anything but the BTS, so > the > BSC/MSC/VLR/HLR functionality is implemented in one binary. > > -- Thanks & Regards Tejas Oza -- Thanks & Regards Tejas Oza

4 29

[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

A problem in OpenBSC, sccp.c
by Wenbin Wu 26 Nov '10

26 Nov '10

Hello, I have a problem in sccp.c. 537--543 udt->type = SCCP_MSG_TYPE_UDT; udt->proto_class = class; udt->variable_called = 3; udt->variable_calling = 5 + out->gti_len; if(out->use_poi) udt->variable_calling += 2; udt->variable_data = 7 + out->gti_len + in->gti_len; if(in->use_poi) udt->variable_calling += 2; I add these two 'if' lines in the code. I'm not sure if it is right. In source code, before it calls 'create_sccp_addr', it sets the length only using gti_len. But in 'create_sccp_addr', if I use poi, the length should be add 2. Am I right?

2 6

Plans for GSM / OpenBSC field test at 27C3
by Harald Welte 28 Oct '10

28 Oct '10

Hi all! As some of you know, we will again have an OpenBSC field test at the Chaos Communication Congress from December 27-30 in Berlin / Germany. I have already applied for the license from the regulatory authority. No feedback yet, but I expect no problems, as it is more or less what we had last year. The only difference is that I've asked for 6 ARFCN (5 last year). It will again be a nanoBTS / GSM 1800 setup. Regarding the overall setup, I want to deviate from what we had last year in the following way: 1) Issue our own SIM cards to permit Authentication + Encryption. This is the perfect way how we can have a A5/1 based network that people can use to play with airprobe + Kraken - without violating any laws. In practise, this will mean we use 16in1 SIM cards, I have already bought 1000 of them. It also means that the GSM helpdesk will have to issue those SIMC cards. I would suggest we simply sell them (as opposed to providing them for a deposit, as we then would have to take back a lot of cards and return money, which is a lot of overhead). We will keep a database of all the IMSI + Ki tuples that we have issued, which we will use as HLR + AuC. This database will be persistent, i.e. at other events like the CCC camp 2011 or 28C3 we expect those SIM cards to be used again without any registration. 2) Provide GPRS + EDGE services using OsmoSGSN and OpenGGSN. I am not sure how stable this will run - but we have a good chacne of catching bugs in our code by running at the event. We will be able to provide real-world IP addresses to every mobile phone, without filter and without NAT ! I am not yet sure how we will deal with dividing the timeslots between GSM and GPRS. The dynamic TCH / PDCH code in OpenBSC hasn't ever been tested, so we might use a static configuration - potentially changing that static config depending on the usage pattern / load we see. 3) Make dual-TRX setups standard (3 BTS with 2TRX each) This is simply to enhance the capacity, particularly of SDCCH/8 resources 4) Consider putting all BTS in the same location area This will significantly reduce our need for signalling channels, but at the expense we no longer know where a particular phone is located in the building. Thus, we might make this optional and see if it is needed for load reasons. 5) Improve the SMS situation The current SMS code still sucks really bad. We don't want this inside OpenBSC, and we still don't do timer-based / automatic delivery. Using the manual 'sms send pending' command causes severe blockage if the queue is getting too large. I will try to squeeze in some time to rewrite this code and make it run as external process. 6) User registration So we sell SIM cards with a pre-programmed IMSI + Ki, but how do we enable users to assign a phone number to them? Ideally I would want them to simply register a phone number at the eventphone.de GURU web interface ahead of the event. But how do we match the IMSI and the phone number? Ask users to simply state the phone number they registered? How do we get some kind of authentication? Comments and additions are most welcome, 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)

5 8

AW: Plans for GSM / OpenBSC field test at 27C3
by Andreas.Eversberg 27 Oct '10

27 Oct '10

>> Each SIM has a 'default' number, and if they want to instead use a number they >> pre-registred, have them text a 'token' (long enough not to guess a >> valid one, but not too long as to be annoying). >> That token is just displayed on eventphone.de when they register a >> number as 'GSM' without an IMSI. > >ok, the other way around. The token is a unique value that they have to SMS to >OpenBSC... great idea. I like it that way. i would like to ask eventphone to add a 10 digits token to the registration tool. this way it is hard enough guess. the token shall be generated randomly when not yet assigned to a phone number. the token is used to authenticate: - by sending SMS with the token (like said above) - by dialing a service number and entering the token - by giving the token to the GSM help desk.

1 0

Changing network data
by Luca Bertoncello 26 Oct '10

26 Oct '10

Hi, list! I'm planing to write a little function in OpenBSC to allow me to change network data in real time (without stopping and starting OpenBSC again). I'd like to change MCC, MNC, ARFCN, LAC and some other cells information. I tried to call shutdown_om for every BTS (just 1) and then bootstrap_bts, but it does not seems to work... Can someone say me what I'm doing false? Thanks a lot Luca Bertoncello -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 23 Fröbelstr. 57, 01159 Dresden Fax: 0351/41381 - 12 _______________________________________________________________________ Impressum: NETZING Solutions AG - Fröbelstraße 57 - 01159 Dresden Sitz der Gesellschaft Amtsgericht Dresden HRB 18926 Vorstand Dieter Schneider - Aufsichtsratsvorsitzender Volker Kanitz USt.Id DE211326547 Mail: netzing.ag(a)netzing.de

2 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC October 2010