OpenBSC February 2017

openbsc@lists.osmocom.org

22 participants
37 discussions

Splitting out M3UA and MTP3 out of Open BSC into a separate library
by Arran Cudbard-Bell 20 Nov '25

20 Nov '25

Hi, Developing a module for FreeRADIUS to support EAP-SIM and EAP-AKA authentication against a HLR. The HLR we were targeting only supported a SCTP/M3UA/SCCP/TCAP/MAP stack, so we couldn't use SUA. Ripping the M3UA/MTP3 code out of OpenBSC worked surprisingly well. We ended up running the event loop in a separate thread to work around the threading issues. Unfortunately the HLR implements the ANSI variant of everything, whereas OpenBSC and supporting libraries seem to have been written to be compatible with the ITU standards. ...but the differences are fairly minor at MTP3 and SCCP layers, and i've started work on a patchset for libosmo-sccp. https://gerrit.osmocom.org/#/c/73/ Anyway, trying to gauge interest in splitting those layers out of Open BSC into a separate library, would be happy to take on M2UA as well for consistency. It would almost certainly get more projects using the code. There's very little out there even in Perl land for working with SS7. Thanks, -Arran Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

6 6

GPRS - local and foreign TLLIs
by Luca Melette 18 Nov '25

18 Nov '25

Hello everybody, after setting up a nanoBTS with OpenBSC/SGSN/GGSN, I had some troubles trying to connect my smartphone to the GPRS cell. Investigating the BTS-to-SGSN traffic, I saw that the frames sent by the SGSN were all marked with the same N(U) value (at LLC layer), the value was 0. With some debug, I found that the there was a mismatch in the TLLI storage, used to keep the status of attached terminals. The mentioned code is contained in gprs_llc.c, involving LL Entity functions and gprs_llc_tx_ui(). /* look-up or create the LL Entity for this (TLLI, SAPI) tuple */ lle = lle_by_tlli_sapi(msgb_tlli(msg), sapi); if (!lle) { struct gprs_llc_llme *llme; LOGP(DLLC, LOGL_ERROR, "LLC TX: unknown TLLI 0x%08x, " "creating LLME on the fly\n", msgb_tlli(msg)); llme = llme_alloc(msgb_tlli(msg)); lle = &llme->lle[sapi]; } The TX function uses the previously received TLLI to lookup for the LLE. The lle_by_tlli_sapi() performs the search, but preliminary it applies a foreign2local TLLI conversion to ensure to have a local one. Since no valid entry for the searched TLLI is found, a new one is created. And the problem is here. The new entry has the foreign TLLI. Next time the lookup fails again, and a new entry is created. This way, the counter N(U) is always reset, and the mobile do not recognize the message sequence and no attach is possible. My question is about foreign and local TLLIs. I patched the lookup, avoiding the conversion, so that the LLE is found and everything works fine... but... What is the sense of the conversion? Should the TLLI be always stored as a local one? Can this problem be solved with another foreign2local while allocating new entries? Actually, my problem has been solved with that workaround. But I'm curious to know what is the right way. Hope somebody can answer :) Thanks. Cheers, LM

4 5

Pysim error: SW match failed
by Martin Nagy 16 Aug '25

16 Aug '25

Hi all, After buying a super Sim Kit (16 in 1) from China, I tried the reader (green PCB inside a blue transparent plastic case with a blue LED) and SIM (identified as a fakesupersim) with pysim tool. However i am getting the following error: /pySim-prog.py -n 26C3 -c 49 -x 262 -y 42 -z 1234 -j 1 -t auto Insert card now (or CTRL-C to cancel) Autodetected card type fakemagicsim Generated card parameters : > Name : 26C3 > SMSP : e1ffffffffffffffffffffffff058100945555ffffffffffff000000 > ICCID : 8949262427518313026 > MCC/MNC : 262/42 > IMSI : 262422461512085 > Ki : 7b74741a1ee14337ec23f9ab92a13648 > OPC : ccd867d60797d8d45354a51b3ef568ff Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 530, in <module> card.program(cp) File "/home/nadicek/pysim/pysim/pySim/cards.py", line 231, in program self._scc.update_binary('6f30', hplmn + 'ff' * (tl-3)) File "/home/nadicek/pysim/pysim/pySim/commands.py", line 53, in update_binary return self._tp.send_apdu_checksw(pdu) File "/home/nadicek/pysim/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed ! Expected 9000 and got 9804. I checked mailing lists and haven’t found anybody who had similar problem with pysim. Also I have tried forcing different models of SIM, but nothing is working. Obviously I can remove this check from the script file (__init__.py in /pySim/transport), however somebody had a reason to put such condition there. I would like to ask if it is safe to remove that line of code and the purpose of that line of code. Thanks a lot and best regards Martin

3 3

Re: Help with sccp library
by mosbah abdelkader 07 Jul '25

07 Jul '25

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

4 3

dynamic traffic channels
by Neels Hofmeyr 20 May '25

20 May '25

On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels

3 5

osmo-sip-connector in bad state
by OMAR RAMADAN 07 Mar '17

07 Mar '17

If the SIP server dies in the middle of a call, osmo-sip-connector is in a bad state and generates a never ending stream of error messages: 58): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f25 It looks like the messages are generated from sofia-sip and I have managed to suppress the messages by setting the environment variable SU_DEBUG < 3: http://sofia-sip.sourcearchive.com/documentation/1.12.7/tport__internal_8h_… However, it looks like osmo-sip-connector is clearly in a bad state when this happens and we need a way to detect and release these ghosted calls.

4 15

Virtual layer 1 - Questions
by Sebastian Stumpf 03 Mar '17

03 Mar '17

Hi, The virtual layer 1 is currently in a state where the l23 app can successfully connect to the bts and most of the signaling messages will be forwarded and handled. TCH is not yet implemented. I have some problems still, not knowing if these are caused by configuration problems or my coding :). - Trying to initiate a call via the mobile vty will result in VTY: call 1 123 OsmocomBB# % (MS 1) % Call has been rejected call 1 123 OsmocomBB# % (MS 1) % Call has been released And no actual call setup message is transfered over the Um interface. What could be reasons for that? I am using the test-sim option the mobile app offers. - Occasionaly the T3210 timer is fired, which causes a new registering within the network. LOG: gsm48_mm.c:336 timer T3210 (loc. upd. timeout) has fired How can i prevent that? - I did not implement a tdma or multiframe scheduler in the mobile uplink as the logical channel is directly put to the gsmtap-header and thus known by the bts. As Harald used a multiframe based scheduling for the bts downlink, i wonder if this might be necessary, though. To submit msgs with the correct frame number for example. - In my wireshark capture files, the gsmtap messages sent over the multicast sockets are only recognized as UDP messages. I have to "cast" them with the wireshark context menu "Decode as...". Why? I would be super happy if someone of you could check out my project (osmo-bts, branch stumpf/virt-phy + osmocom-bb, branch stumpf/virt-phy) try to run it with the config files lying within the project folders and tell me the problems they see :). Here you can find a wireshark capture file of 2 mobiles connecting to a virt bts. I also tried to init calls from both of them but the call setup is not send. https://www.dropbox.com/s/2ccky4ljc8ngahz/mobilex2--ms-virt--bts-virt--bsc-… Kind Regards, Sebastian Stumpf

2 7

libosmo-netif failed on both jenkins FreeBSD and xUbuntu_16.04/i586
by Neels Hofmeyr 28 Feb '17

28 Feb '17

It seems to be a sporadic failure due to timing. Kicking off the same build on jenkins resulted in success. Can anyone relaunch the OBS build? I'm not too familiar with it... http://jenkins.osmocom.org/jenkins/job/libosmo-netif/ https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/l… Also, it would actually be nice if the opensuse builds also printed all test logs as in osmo-ci/scripts/cat-testlogs.sh -- if anyone knows how and has the time to insert such, that would be great. (git clone https://gerrit.osmocom.org/osmo-ci) Thanks, ~N

2 1

Handover and load balancing on SysmoBTS 2050
by Keith 27 Feb '17

27 Feb '17

Hi list, Hi all. This is quite Rhizomatica, or at least litecel 2050 specific, please excuse me for that. I also don't know, maybe it applies to other use cases. Rhizomatica has one community where an attempt was made to increase coverage at the same time as capacity, by installing two 2050s with a somewhat overlapping coverage area. We have currently plans to do the same in other places. The goal of this email is to try to establish the work needed to be done in order to fix what I outline below, I may just be lacking knowledge in some cases, in other It seems we need to implement some things. I have grabbed fairwaves' meas_json and meas_web and modified a little to give me a visualisation of the neighbour meas reports. So my first doubt is about idle cell reselection on the part of the MS. It doesn't seem to be operating quite as I would imagine it should and I am wondering is there any parameter that might make a difference, such as cell_identity? Is cell reselection hysteresis/offset relevant when handover is disabled? These parameters are not described in the manual. If I understood them I could update that. In the meantime, we seem to be getting reports from users that "the signal is weak" near what I might call the secondary BTS. At the same time, user reports are not terribly reliable. However what seems to be happening is that the MS is camped on the primary BTS, subsequently they have moved away so their handset is showing less 'bars'. I'm sometimes seeing TCH in use on the primary BTS that are showing neighbour measurements from the secondary that are more favourable. Of course, I am often seeing messages such as: handover_decision.c:203 (bts=3,trx=0,ts=2): Cell on ARFCN 242 is better: Skipping, Handover disabled Obviously, this makes sense, and I am not sure why historically we have handover disabled, I presume it is issues with rtp, although we are using the rtp_proxy. I don't have two BTS so I can't test locally here. Could anybody comment on the state of that? I am assuming that there is no way we can do load balancing unless we first have handover enabled, at the same time it is unclear to me if it will even work with handover. I believe this is called "Traffic Handover" Is this already implemented in the BSC? As in, can the BSC assign a channel on another ARFCN to the MS if the current ARFCN (the one the MS makes the access request on) has no TCH available? I also have a doubt about operation with a Litecel/2050. Obviously you don't really want rescue handover operating between the two BTS that are present in the Litecel as it is the same antenna, and this shouldn't happen anyway as the signal levels should never be sufficiently different, but we do want load balancing handover. I do see "no resources available" log messages, (especially related to the BROKEN channels issue) when one BTS in a litecel has no more capacity but the other does, so it would seem that the BSC is not managing this. Is that correct? Would it be correct to assume that maybe some handover rules are required that would specify: Handover from BTS 0 to BTS 3 but not from BTS 0 to BTS 1? Finally, I have a doubt about the rtp proxy mode. Was it ever discussed to implement SIP Mobility aka re-Invite in order to be able to do BTS-MGW rtp and also handover? This would seem to me to be a good thing to have? k/

5 14

vlr+hlr: Insert Data
by Neels Hofmeyr 27 Feb '17

27 Feb '17

What should we do if the HLR sends no Insert Data? When a subscriber does a Location Updating, the VLR sends a Location Updating request to the HLR. The HLR typically responds with a Location Updating Result as success and, in a *separate* message, sends an Insert Data to the VLR to tell it the subscriber's MSISDN. So it is possible to do a successful Location Updating without being told the MSISDN (as my test verifies). What should the VLR do if it never receives the Insert Data from the HLR? In that case the subscriber is attached but cannot be reached by MSISDN. Should we actively wait for Inser Data and reject the subscriber if not successful? It would be fairly easy to just send the MSISDN along in the Location Updating Result. Why this separate message? Thx, ~N

4 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC February 2017