OpenBSC

openbsc@lists.osmocom.org

12 participants
4278 discussions

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

01 May '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 01 May '12

01 May '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 01 May '12

01 May '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 27 Apr '12

27 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

sgsn/ggsn bitrate tests and reflexions
by carcelle 26 Apr '12

26 Apr '12

Hi dear osmocom folks, I have been doing some bitrate throughput tests from different MS (i.e. phones models) connected to a working osmo-nitb/sgsn/ggsn configuration (with a nanoBTS DCS1800) and i get 15kbits/s maximum (tcp/udp transfer) with the gprs subnet nat-ed to a 100baseT lan connected to a 2Mbits/s dsl line The channel configuration is as follow in the osmo-nitb configuration file : <file /etc/osmocom/bsc.conf> (...) nominal power 23 max_power_red 0 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 ! hopping enabled 0 timeslot 1 phys_chan_config TCH/F ! hopping enabled 0 timeslot 2 phys_chan_config TCH/F ! hopping enabled 0 timeslot 3 phys_chan_config TCH/F ! hopping enabled 0 timeslot 4 phys_chan_config TCH/F ! hopping enabled 0 timeslot 5 phys_chan_config TCH/F ! hopping enabled 0 timeslot 6 phys_chan_config TCH/F ! hopping enabled 0 timeslot 7 phys_chan_config PDCH </file> Should i change the channel configuration to get more bitrate ? Should add more cells (bts?) to add more channels ? my best, cheers. Xavier.

2 3

PCAP and CFG Files for NanoBTS with GPRS "unknown TLLI" issue ...
by John 25 Apr '12

25 Apr '12

Peter Suge wrote: >Please send the pcap file as requested. It includes significant >detail which is not shown in console messages. You can use tcpdump >to create the file from the command line, or even wireshark. Here is the pcap: https://docs.google.com/open?id=0B1aXbMU98OahcWp3cVRRWEJBeHc The phone cannot communicate any GPRS data after the message in packet 480 (sent upon power up), which is also when the console shows a message like this below (not actual message from attached pcap): <0012> gprs_bssgp.c:347 BSSGPTLLI=0x7d3b6971 Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1C FCS=0x35b15fCMD=UI DATA <0013> gprs_llc.c:742 LLC RX:unknown TLLI 0x7d3b6971, creating LLME on the fly Others on this mailing list asked for the config files. Here is the nanobts config, which follows the example on the instructions in the wiki for GPRS, with the main differences being allowing all devices to attach and I set the IP addresses. Also, I put the PDCH in the last two timeslots. https://docs.google.com/file/d/0B1aXbMU98OahcGFFWkRIcE54NDQ Here is the SGSN config: https://docs.google.com/open?id=0B1aXbMU98OaheVFqdUhYZWkwQzg There are some strange things in the BCCH configuration in packet #240 of the pcap that don't match configuration files. For example, I have set cell reselection hysteresis as shown in the openbsc.cfg to 4, but the BCCH configuration packet #240 has the value of 2. Let me know if you see anything, and I appreciate your feedback. John

1 0

Issue with GPRS for nanoBTS: no SGSN IP sent to nanoBTS ...
by John 25 Apr '12

25 Apr '12

Hi, I have an ipaccess nanobts model 165AU. I have followed the instructions for GPRS on the OpenBSC with a fresh install of Ubuntu 11.10: http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS By adding the IMSIs for two GPRS capable handsets to the database and assigning extensions, the phones will attach and I can make calls between the handsets. However, there seems to be no functionality related to GPRS. A couple of of different iPhones in GPRS field test mode won't pick up GPRS-related parameters in "filed test mode", such as they won't see different values I try for T3192 timer or DRC Timer Max. Note that I see changes I try for these parameters (T3192 and DRC Timer Max) sent to the nanobts from the wireshark packet captures. These same iPhones can make phone calls through the nanoBTS/OpenBSC. Probably, the most significant underlying issue is that I don't see the SGSN IP address ever sent to the nanoBTS anywhere in the Wireshark packet capture. It's clearly set in my configuration line "gprs nsvc 0 remote ip 192.168.XXX.YYY", and again I'm using an exact copy of the instructions linked above. So, GPRS clearly won't work without the nanoBTS "knowing" the SGSN. I do see the link between SGSN and GGSN, and the SGSN/GGSN both "up", but no traffic of course between the nanoBTS and SGSN. Note that I also did some searching and I saw one posting where the configuration line "gprs mode gprs" should be "gprs mode egprs", but that didn't make any difference. Does anyone have suggestions of what might be wrong or what I should look at? Thanks, John

4 4

April 25, 7pm / Regular Osmocom meeting in Berlin?
by Harald Welte 24 Apr '12

24 Apr '12

Hi all! This is the announcement for the 2nd incarnation of our bi-weekly Osmocom Berlin meeting. April 25, 7pm @ CCC Berlin, Marienstr. 11, 10113 Berlin The schedule is as follows: 19:00 Introduction into the TETRA base station located @ CCCB For quite some time, there is a full TETRA base station located in the Berlin CCC, consisting of two base radios (BR), a site controller (TSC), an auto-tuning cavity combiner and other equipment. The talk will introduce the architecture of the system and the current status of getting it running. 20:00 Presenting the CC32RS512 / towards an Osmocom Card OS The CC32RS512 is a flash-based smart card controller to which the documentation is available without NDA. This means that we finally are able to implement a Smart Card OS (COS) as free software. 20:30 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:30. 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC