- OpenBSC - lists.osmocom.org

Sagem OT-290 trace phone / GSMTAP integration
by Harald Welte 07 May '12

07 May '12

Hi all! Thanks to a generous donor, we have received a couple of OT-290 trace phones. These are commercial products intended for taking L2/L3 air interface traces. If you've read any of the fabulous GSM papers by Prof. Dr.-Ing. Joachim Goeller: The OT-phones is what he used to generate all his traces. The majority of what those phones can do is now also possible with OsmocomBB. However, OT-290 support GPRS tracing/testing - for CS-1 throguh CS-4. I would be willing to give away one of the two remaining OT-290 (for free) to anyone who would in return commit to developing a GSMTAP interface for it. The message format on the serial UART between phone and PC is documented (PDF documentation by Sagem included with the phones). So based on this documentation and an OT-290 phone, it should be possible to write a small command-line program that receives the GSM/GPRS messages from the OT-290 and sends them via GSMTAP into wireshark. The result would then be similar to what http://cgit.osmocom.org/cgit/dct3-gsmtap/ is for DCT-3 phones. If you're interested, please respond to this message. Please don't apply for the phone if you are not able to find the required time and interest for actually doing the GSMTAP integration. Thanks! -- - 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 2

GPRS Problems with Nokia Handsets
by Olaf Schulz 06 May '12

06 May '12

Hello, I use OpenBSC/GPRS (sw version only few weeks old) with nanoBTS and this works well mith many mobile devices. With Nokia devices, however, I do not get a PDP context. Here is an osmo-sgsn trace of Nokia E65: <0012> gprs_bssgp.c:347 BSSGP TLLI=0x795b37eb Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0xc2ab0aCMD=UI DATA <0013> gprs_llc.c:742 LLC RX: unknown TLLI 0x795b37eb, creating LLME on the fly <0002> gprs_gmm.c:636 -> GMM ATTACH REQUEST MI(001011474110317) type="GPRS attach" <0002> gprs_gmm.c:351 <- GPRS ATTACH ACCEPT (new P-TMSI=0x78bb36bb) <0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS <0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS <0012> gprs_bssgp.c:347 BSSGP TLLI=0xf8bb36bb Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0xc2ab0aCMD=UI DATA //remark: is a repetition of GMM ATTACH REQUEST <0013> gprs_llc.c:525 TLLI=f8bb36bb dropping UI, N(U=0) not in window V(URV(UR:1). <0012> gprs_bssgp.c:347 BSSGP TLLI=0xf8bb36bb Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x478a8dCMD=UI DATA <0002> gprs_gmm.c:1047 -> ATTACH COMPLETE <0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS <0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS <0012> gprs_bssgp.c:347 BSSGP TLLI=0xf8bb36bb Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x478a8dCMD=UI DATA //remark: is a repetition of ATTACH COMPLETE <0013> gprs_llc.c:525 TLLI=f8bb36bb dropping UI, N(U=1) not in window V(URV(UR:2). <0012> gprs_bssgp.c:347 BSSGP TLLI=0xf8bb36bb Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x29e399CMD=UI DATA <0002> gprs_gmm.c:782 -> GMM DETACH REQUEST TLLI=0xf8bb36bb type=GPRS detach <0002> gprs_gmm.c:425 <- GPRS DETACH ACCEPT <0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS <0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS <0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS We see some dropped frames here which are in fact retransmissions sent by the Nokia device. After the successful GPRS Attach, the Nokia device refuses to send an ACTIVATE PDP Context REQ. Most Nokia devices get asked for IMSI and IMEI during the GPRS ATTACH, which her does not happen. However, these retransmissions are characteristical for all Nokia devices I've tested so far (6021, C5, C7, E65, 3109c). Is there a timing problem between osmo-sgsn and Nokia devices? Can I tune osmo-sgsn's parameters to make the connection work? Any help would be appreciated. cheers Olaf ---------------------------------------- -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

3 2

SIM Card Sources
by Duncan Smith 06 May '12

06 May '12

Hello, Does anyone have recommendations for obtaining SIM cards? I'm trying to get at least 500, unprinted and unprogrammed. Ideally, I'd be able to buy 1,000 (or more) cards for around USD$1,000 total, but I'd be willing to go up to 5,000 cards if the price drops to something like USD$0.50 per card. Thanks! -- Duncan Smith http://xrtc.net/f/

2 1

May 09, 7pm / Osmocom meeting in Berlin
by Harald Welte 02 May '12

02 May '12

Hi all! This is the announcement for the 3rd incarnation of our bi-weekly Osmocom Berlin meeting. May 09, 7pm @ CCC Berlin, Marienstr. 11, 10113 Berlin The schedule is as follows: 19:00 Introduction / Workshop on Osmocom SIMtrace (Kevin Redon) Kevin will introduce SIM/USIM/UICC cards, present what SIMtrace is and how it works, as well as how to use it to trace communication between SIM card and phone. 20:00 Informal discussions If you are interested to show up, feel free to do so. There is no registration required. If the initial part is not interesting to you, feel free to join us later at 20:00. The meeting is free as in "free beer", despite no actual free beer being around ;) 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)

1 0

Re: gprs_llc.c: foreign TLLI is stored, but not searched
by VID - Frank Maas 30 Apr '12

30 Apr '12

Holger wrote: > wanted to avoid this issue is that whoever transmits needs to select the > llme/lle. I think my code set old_tlli to the foreign or such but I dropped it > (and can't remember why it wasn't needed anymore). Been there, tried that. It wasn't so much that is wasn't needed, but elsewhere in the code old_tlli (and especially the fact if it is 0xffffffff or not) is used to (re)set some stuff. > This will not be the last issue you will experience with GPRS. Both the > nanoBTSs implementation and our SGSN are not very stable. Well... only 7 hours of Qday to go ;-) > Some of the known GPRS issues include: > > - http://openbsc.osmocom.org/trac/ticket/55 (crash) I solved that one > - http://openbsc.osmocom.org/trac/ticket/44 (correctness) > - http://openbsc.osmocom.org/trac/ticket/43 (leak) Will check these. > There is also the 'santos' branch of someone that forked our code and has > done a bit of bugfixing. Ah ok. I'll look into that. Might be of use during the last couple of hours HTH/F

3 3

gprs_llc.c: foreign TLLI is stored, but not searched
by Frank Maas 30 Apr '12

30 Apr '12

I might be horribly wrong, but there is something I did not grasp in gprs_llc.c. So I altered it, but since I am not sure I share it here... Function 'gprs_llc_tx_ui' uses function 'lle_by_tlli_sapi' to retrieve an lle based on a tlli/sapi combination. To do the lookup, the supplied tlli is 'localized' (tlli_foreign2local). If this does not result in a succesful find, function 'llme_alloc' is used to "create an LLME on the fly". However 'llme_alloc' does not localize the tlli. So every next search for the lle fails. For this I created this patch: --- openbsc/openbsc/src/gprs/gprs_llc.c 2012-04-30 15:42:58.958823325 +0200 +++ ../openbsc/openbsc/openbsc/src/gprs/gprs_llc.c 2012-04-30 10:54:11.291836887 +0200 @@ -157,7 +160,8 @@ if (!llme) return NULL; - llme->tlli = tlli; + llme->tlli = tlli_foreign2local(tlli); llme->old_tlli = 0xffffffff; llme->state = GPRS_LLMS_UNASSIGNED; This seems to have solved the problem (unable to get an IP link operational), but I am not sure if this was the correct way to handle this, so please feel free to comment. HTH/F

2 1

[SHOWCASE] OpenBSC used during Queensday (NL)
by VID - Frank Maas 30 Apr '12

30 Apr '12

Goodafternoon, This is just a quick email to let you know that we are currently (as in: today) using OpenBSC to offer a GPRS service to some equipment during Queensday. For those of you that do not know this: Queensday is a Dutch festivity where the birthday of the Queen is celebrated. It attracts a mass of people and under that condition no (normal) mobile network will stay operational. Since we have some equipment running, we decided to try out creating our own mobile network. For this we installed several ip.access nanoBTSes and use OpenBSC as central software. Unfortunately this is not a complete success. Although we tested it and those tests gave us confidence, we now experience a lot of connection losses. Several nanoBTS'es bootstrap quite regularly, and almost all connected devices are unreachable after several minutes (some later than others). Only restarting OmniBSC quite often seems to bring back some life. Up until now I have been unable to find out why things are wrong. While preparing for this use of OpenBSC I came accross some things that might be worthwhile to share with you. I'll do that in separate messages, so contents does not get clobbered. Please allow me to thank you all for the great work you have done in this set of software. I hope some of my experiences will help you pushing this forward. Kind regards, Frank

3 2

OpenBSC (GPRS) on VMWare/ESXi 4: UDP problem
by VID - Frank Maas 30 Apr '12

30 Apr '12

Please be aware of a problem in ESXi in which the checksum of UDP packets is wrongly calculated. This will cause the UDP traffic from the SGSN to the BTS'es (vice versa) to fail. It can take quite a while to figure this out (well... to be honest all it takes is a good look at the extended tcpdump output, but hey). If you experience problems setting up GPRS (symptom: NSVC remains ALIVE BLOCKED), try this command: ethtool --offload eth0 rx off tx off gso off (with eth0 the correct interface, or better: for all interfaces). This works under CentOS (tested) and Debian/Ubuntu (read about it). HTH/F

1 0

LAPDm / RSL EST IND
by Harald Welte 29 Apr '12

29 Apr '12

Hi jolly, I'm seeing some strange behavior on the BTS side LAPDm code: When we get a SABM on SAPI=3 from the phone, this gets translated into an RSL_RLL_EST_IND. However, as there commonly is no l3 payload in a SAPI=3 SABM, the L3_INFO IE should not be present in that message. Instead of a RLL_EST_IND without L3_INFO IE, we get a L3_INFO IE that consists only of 1 byte tag and 2 byte length, but not payload. The Length value seems non-deterministic, i.e. like uninitialized memory. I've tried to resolve this, and I suspect it is somehow related to the DUMMY msgb that the lapd code allocates (why is it doing that?) in send_dl_simple(). The code path should be: lapd_rx_u() if (length == 0) send_dl_simple() send_rslms_dlsap() here we check for (!dp->oph.msg), but since there is a dummy msgb, we probably run into the send_rslms_rll_l3() case instead of send_rll_simple(). What do you think is the best way to resolve this? Thanks, 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 2

Developer room @ FrOSCon 2012 ?
by Harald Welte 26 Apr '12

26 Apr '12

Hi all, I have received the following invitation from the FrOSCon team. Please let me know if anyone is already intending to attend the conference, or would be interested in getting together thre in a devroom. I'm personally not so sure since we already had the OsmoDevCon earlier this year... but then, late August is almost half a year later ;) ------------ Hello OpenBSC Team, we would like to invite you to take part in the seventh Free and Open Source Software Conference (FrOSCon 2012). FrOSCon is a two-day conference on Free Software and Open Source, which takes place on August 25th/26th, 2012 at the University of Applied Sciences Bonn-Rhein-Sieg, in St. Augustin near Bonn, Germany. Main part of the conference is a comprehensive range of talks and workshops. Furthermore, there is a large exhibition area, where projects have the opportunity to present themselves and get in touch with users and other developers. Moreover, we offer a few rooms for Free Software projects to organize developer meetings or to present their own program. We would be pleased if your project would like to contribute to this year's FrOSCon and thus support the communication and exchange within the Open Source and Free Software community. Depending on the kind of your participation, there is different information available to you. To sign up for a booth, please visit https://callforexhibitors.froscon.org and register your project. Please feel free to contact us for any questions at exhibitors(a)froscon.org <mailto:exhibitors@froscon.org>. The registration for booths will be open until May 23rd. If your project wants to sign up for a developer room, please write a proposal to projects(a)froscon.org <mailto:projects@froscon.org>. The proposal should contain a short summary (1-2 paragraphs) of what you plan to do and which special requirements you have. Since the demand for developer rooms usually exceeds the number of rooms we can offer, we will choose the projects which look the most promising to us based on the submitted proposals. If you have questions concerning the developer rooms, feel free to contact projects(a)froscon.org <mailto:projects@froscon.org>. The deadline for the submission of developer room proposals is April 30th. Additionally our Call for Papers already started, we are looking forward to your submissions of talks and workshops. You can register via http://cfp.froscon.org/. For further information concerning the Call for Papers take a look at http://www.froscon.de/en/program/call-for-papers/. The Call for Papers will end on May 23rd, too. We hope to meet you at FrOSCon in St. Augustin. Kind regards, The FrOSCon Team ----------- -- - 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)

1 0