OpenBSC

openbsc@lists.osmocom.org

17 participants
4202 discussions

Request for help on the BSC API
by Holger Hans Peter Freyther 17 Jun '10

17 Jun '10

Hi, I landed the first big change, the gsm48_rcvmsg is now inside the bsc_api.c. And on first msg the BSC API will call the compl_l3 (COMPLETE LAYER3) callback. This method will always be called for any new connection and is the perfect place to enable encryption.. I would be very happy if someone could take the task and change the osmo_msc.c and gsm_04_08.c to first make use of the ACCEPT/REJECT policy and then enable the auth/security on this new connection and then dispatch the original message (but CM Service Reject). Another task would be to move the Cipher Mode code into the BSC API, the gsm_04_08.c code should not directly change the attributes in the lchan and should not send the cipher mode RR message. The next thing to kill is the unconditional usage of &lchan->conn as I will start allocating the conn dynamically... (one conn can have multiple lchan's for handover and early assignment). I will now work on refcounting and moving the transaction into the subscriber connection...(some other work before) so I will probably not make it before sunday as I will be out of town. regards holger

2 1

AW: Problem compiling OpenBSC on Kubuntu Hardy
by Andreas.Eversberg 17 Jun '10

17 Jun '10

diff --git a/openbsc/src/gsm_04_11.c b/openbsc/src/gsm_04_11.c index 57d8089..faa5f69 100644 --- a/openbsc/src/gsm_04_11.c +++ b/openbsc/src/gsm_04_11.c @@ -340,14 +340,14 @@ static unsigned long gsm340_validity_period(u_int8_t sms_vpf, u_int8_t *sms_vp) /* ignore additional fi */ if (fi & (1<<7)) sms_vp++; /* read validity period format */ - switch (fi & 0b111) { - case 0b000: + switch (fi & 0x7) { + case 0x0: return gsm340_vp_default(); /* no vpf specified */ - case 0b001: + case 0x1: return gsm340_vp_relative(sms_vp); - case 0b010: + case 0x2: return gsm340_vp_relative_integer(sms_vp); - case 0b011: + case 0x3: return gsm340_vp_relative_semioctet(sms_vp); default: /* The GSM spec says that the SC should reject any ---------- -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther Gesendet: Donnerstag, 17. Juni 2010 16:26 An: openbsc(a)lists.gnumonks.org Betreff: Re: Problem compiling OpenBSC on Kubuntu Hardy On 06/17/2010 10:20 PM, Luca Bertoncello wrote: > Hi, List! > > gsm_04_11.c:364:8: Fehler: ungültiger Suffix »b011« an Ganzzahlkonstante Your compiler does not like to have numbers in binary, please prepare a patch (I say that once a month and then nothing happens) to use these in hex.

3 2

Problem compiling OpenBSC on Kubuntu Hardy
by Luca Bertoncello 17 Jun '10

17 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, List! I'm trying to compile OpenBSC (last version from GIT) on my KUbuntu Hardy (8.04). Unfortunately, I get this error: make[3]: Betrete Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src' gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I.. -Wall -I/usr/local/include/ -I/usr/local/include/ -g -O2 -MT gsm_04_11.o -MD -MP -MF .deps/gsm_04_11.Tpo -c -o gsm_04_11.o gsm_04_11.c gsm_04_11.c:357:16: Fehler: ungültiger Suffix »b111« an Ganzzahlkonstante gsm_04_11.c:358:8: Fehler: ungültiger Suffix »b000« an Ganzzahlkonstante gsm_04_11.c:360:8: Fehler: ungültiger Suffix »b001« an Ganzzahlkonstante gsm_04_11.c:362:8: Fehler: ungültiger Suffix »b010« an Ganzzahlkonstante gsm_04_11.c:364:8: Fehler: ungültiger Suffix »b011« an Ganzzahlkonstante gsm_04_11.c: In Funktion »gsm340_rx_tpdu«: gsm_04_11.c:563: Warnung: Vergleich ist durch beschränkten Wertebereich des Datentyps stets »unwahr« make[3]: *** [gsm_04_11.o] Fehler 1 make[3]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src' make[2]: *** [all-recursive] Fehler 1 make[2]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc' make: *** [all] Fehler 2 I see the line in gsm_04_11.c and it seems OK. What is the problem? Ubuntu Hardy uses gcc 4.2.4. Thanks a lot! - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMGi88AXzltVKV/2wRAvkcAKCehGaHly78lnO1j7DXdzk72lPycgCfYVzd 9RIkN4/q3i3Es4Y0HIFLJpk= =u1eY -----END PGP SIGNATURE-----

3 2

Re: open bsc and lcr: layer_3 thread read socket error
by Richard Zahoransky 16 Jun '10

16 Jun '10

-------- Original-Nachricht -------- > Datum: Tue, 15 Jun 2010 21:02:12 +0800 > Von: Holger Freyther <zecke(a)selfish.org> > An: openbsc(a)lists.gnumonks.org > Betreff: Re: open bsc and lcr: layer_3 thread read socket error > On 06/15/2010 08:19 PM, Richard Zahoransky wrote: > > Hello, > > > > my name is Richard and I am working on OpenBSC and LCR for my > university. We plan to deploy a GSM-Network on the campus for research. > > Hi, > > where is that university located? It is the Albert-Ludwigs-Universität in Freiburg, Baden-Württemberg, Germany. > I can't help with LCR but as a general > hint you can use strace and at least see which filedescriptor returned > that error, it might be a hint. > > Have you tested the BTS with something like bsc_hack? Does this work? > Yes, bsc_hack works with no problems. Thank you for your advice! We have solved the problem. We simply didn't load the mISDN_dsp module. We did not integrate the mISDN_l1loop into the kernel but start it with insmod mISDN_l1loop.ko (located in a subfolder of the mISDN-Folder after running 'make') Still, if we load the l1loop with -nchannel=30 the lcr would somtimes print out the already said error message but it doesn't hang. It is then still possible to place a phone call from the cell phones. As workaround, we load the module with 8 channels instead of 30. It seems to work without the error message. Only one error is left. LCR prints: 'ERROR Port 1 already in use by LCR. You can't use a NT port multiple times.' On startup. Outgoing calls work but we still have to test incoming calls.

1 0

Status of the BSC/MSC API split
by Holger Freyther 16 Jun '10

16 Jun '10

Hi all, here is just a small information of what is going on and what will happen in the near future. Done: - Create bsc_api.c for the BSC API handling - Create osmo_msc.c for the callbacks... - Start to remove lchan usage from MSC code What will happen: - No MSC code will directly touch/use/know about the lchan - Move the gsm48_recvmsg into the BSC API and dispatch - The transaction will be anchored inside the subscriber con and no transactions will clear the channel immediately - Need to add API for Cipher, Handover, Assignment handling - pick a better name for subscriber_connection. What can happen after this: - We can reimplement the bottom of the BSC API with SCCP and have a true MSC codebase... If any of you is adding new L3 code, please do not use the LCHAN directly but the subscriber connection. thanks holger

1 0

AW: Operation management in the MSC code
by Andreas.Eversberg 15 Jun '10

15 Jun '10

>1.) kill the transaction... >2.) generalize it with the "operation". Right now we do have two >operations, one for LU, one for AUTH, we should have them for USSD, SMS >and CC as well. hi holger, the "transaction" represents the instance of calling party / called party / sms sender / ... will the states of it be moved to the "operation"? (e.g. call state, transaction_id, callref, protocol) in this case the call control / sms must use "operation" instance instead. i currently use "transaction" in osmocom-bb for call control and later sms and supplementary services. i think that the sms code should be re-usable in osmocom-bb, so the "operation" instance should be equal (defined in libosmocore) and the sms function sould be available in something like a "libsms", like the "libvty". note: osmocom-bb is at a point where SMS could be sent and received, if a shared sms library would be available. andreas

3 2

open bsc and lcr: layer_3 thread read socket error
by Richard Zahoransky 15 Jun '10

15 Jun '10

Hello, my name is Richard and I am working on OpenBSC and LCR for my university. We plan to deploy a GSM-Network on the campus for research. We have successfully installed OpenBSC, Asterisk, LCR and mISDN. Lcr starts correctly (as far as I can say). The nanoBTS connects to OpenBSC and boot up. On the local machine, we can place outgoing calls with asterisk but when we dial from the cellphones, the lcr prints out: "layer3_thread read socket error No space left on device". I don't know if this is an error in LCR, OpenBSC, mISDN or just in my own config files. We ran through the How-to "OpenBSC_LCR" on http://openbsc.osmocom.org/trac/wiki: gsm is enabled in options.conf GSM interface is active in interface.conf mISDN_l1loop interfaces are created and the routing.conf looks also as described: ----------------------routing.conf (lcr)---------------------- [main] interface=GSM : remote application=asterisk context=btsctrl #interface=xyz : goto ruleset=xyz extern : goto ruleset=extern intern : goto ruleset=intern : disconnect cause=31 ------------------------------------------------------------- the rest of the file is untouched. on the local asterisk, the chan_lcr.so is loaded. the context btsctrl is defined is the extensions.conf: ----------------------extension.conf (asterisk)-------------- [default] exten => _0.,1,Dial(SIP/10${EXTEN}@comsys02) [btsctrl] exten => _X.,1,Set,CALLERID(num)=5552342 exten => _X.,n,dial(SIP/10${EXTEN}@comsys02) ------------------------------------------------------------- it connects to the remote asterisk server as user comsys02, defined in sip.conf ----------------------sip.conf (asterisk)-------------------- register => comsys02:xxx@132.230.4.8/comsys02 [general] port=5060 bindaddr=0.0.0.0 [btsctrl] type=friend context=default secret=xxx host=dynamic [comsys02] type=friend context=btsctrl username=comsys02 fromuser=comsys02 secret=xxx host=132.230.4.8 qualify=yes nat=yes ------------------------------------------------------------- now everything seems to work, but when i dial a number, it prints out: "layer3_thread read socket error No space left on device", many times per second. On the phone I hear static noise. lcradmin prints out the following: ACTION (match) action remote line 8 EP(1): ACTION remote (setup) number 076719235 remote as* EP(1): SETUP ACKNOWLEDGE to CH(1) EP(1): TONE to CH(1) directory default name dialing EP(1): TONE to CH(1) directory default name cause_10 EP(1): DISCONNECT to CH(1) cause value=16 location=1-Lo* CH(1): MNCC_DISC_REQ LCR<-BSC port 1 progress coding=3 * CH(1): MNCC_REL_IND LCR<-BSC port 1 cause coding=0 loca* EP(1): RELEASE from CH(1) cause value=31 location=1-Loc* EP(1): ACTION hangup and the local asterisk output is: NOTICE[10941]: chan_lcr.c:1731 handle_retry: [call=NULL ast=NULL] Retry to open socket. NOTICE[10941]: chan_lcr.c:364 send_message: [call=NULL ast=NULL] Sending MESSAGE_NEWREF to socket. maybe someone also encountered this problem or can help us with the configuration many thanks in advance and best regards, richard

3 2

AW: open bsc and lcr: layer_3 thread read socket error
by Andreas.Eversberg 15 Jun '10

15 Jun '10

hi, first try the bsc_hack. it has a bult-in MSC, so you can call from mobile phone to mobile phone. if this works, try to use LCR without asterisk. if you have no ISDN card, then you can also dial via LCR from mobile to mobile. if this works, then try asterisk... andreas On 06/15/2010 08:19 PM, Richard Zahoransky wrote: > Hello, > > my name is Richard and I am working on OpenBSC and LCR for my university. We plan to deploy a GSM-Network on the campus for research.

1 0

Operation management in the MSC code
by Holger Freyther 15 Jun '10

15 Jun '10

Hi, I am going through the SMS code right now and try to convert it to the BSC API and there is something that is quite bad. There are many paths were sending a SMS can end, some do not free the SMS, some not the transaction, some do not remove lock on the channel. I would like to make the radical proposal to solve that. 1.) kill the transaction... 2.) generalize it with the "operation". Right now we do have two operations, one for LU, one for AUTH, we should have them for USSD, SMS and CC as well. Each gsm_subscriber_connection (MSC data) has an operation manager, when a lchan is opened we will attempt to create an operation for the initial message, at the end of one operation the operation manager will check if all operations are completed and then send a clear using the BSC API. The consequence of that is: 1.) we get rid of the refcount and can close channels faster 2.) we will notice... when we run into a timeout and should not... I know this will be a bigger change on the MSC side of things but what do you guys think about it? z.

2 1

GPRS/SGSN progress update
by Harald Welte 11 Jun '10

11 Jun '10

Hi all, I've been working on the SGSN code again for two days, and there is quite a bit of progress, even if it doesn't really make much difference in what you can do. I'm still working on the signalling plane, an we still cannot send/receive user plane packets (the actual TCP/IP). However, a number of bugs / misunderstandings have been fixed: 1) When we send BSSGP Downlink-Unitdata, we have to always include the IMSI of the target phone, as well as the "MS Radio Access Capabilities" IE. This is apparently needed for the BTS to know when and how it can schedule packets to be sent on the radio interface. However, I personally think it's an ugly layering violation. All this information is part of the "GMM State" in the SGSN, i.e. higher than layer3. It now needs to be passed through LLC down into BSSGP, where it is used :( 2) LLC UI Frames have sequence numbers that need to be incremented with every frame. 3) Some phones apparently don't like it if they don't get a P-TMSI allocated during GPRS ATTACH and ROUTEING AREA UPDATE. According to the spec, it's optional and I thought I could skip that feature to make things easier initially. 4) There are two levels of C/R (Command/Response) bits, one at the LLC and the other at the BSSGP layer. The LLC bit is now set correctly, but the BSSGP C/R packet seems to be set even wrong by the BTS. However, I'm now simulating the behaviour of exissting Gb protocol traces 5) The 04.08 GMM timers T3350 and T3370 have been implemented properly, including re-transmissions of the according MM frames 6) As part of P-TMSI Reallocation, there are time windows when the SGSN has to consider both the old and the newly allocated P-TMSI are valid simultaneously Finally, I've found one other bug that I'm about to fix now: When we assign a new P-TMSI, this implicitly means that the TLLI will change, too. Since the TLLI changes, the LLC protocol created a new "LL Entity" data structure and re-started the sequence number at 0, resulting in all messages being dropped in the phone until the sequence number is higher than the previous one. I have some hope that this is the last bug before I can see packets on the data plane coming out the TUN device on OpenGGSN. After that, there are still the following major TODOs: * actually check the HLR rather than accepting every IMSI * implement BSSGP flow control for BVC and MS level * implement SNDCP fragmentation/reassembly Followed by more optional features, such as * implement SNDCP header compression * implement SNDCP payload compression * implement LLC re-transmissions * implement GEA3 encryption 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 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC