OpenBSC February 2019

openbsc@lists.osmocom.org

15 participants
25 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

ip.access nano 3G S8 Configuration
by John Thewlis - Meath Broadband 18 Nov '25

18 Nov '25

We are trying to setup this AP as part of the 3.5G Osmocom project. We have the software stack operational and are now preparing the nano for testing. When we try to login via telnet at port 8090 we are getting a constant refusal to connect:- root@osm/openbsc/openbsc/src/ipaccess# telnet 192.168.192.30 8090 Trying 192.168.192.30... telnet: Unable to connect to remote host: Connection refused The device seems to be locked as indicated by the leds on the front panel. We have tried resetting the nano to see if this would help but to no avail. Any ideas as to how to access the device for initial configuration?. Thanks John

4 4

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

Need nano3G (S8 - Model 237A)
by Akib Sayyed 18 Nov '25

18 Nov '25

Dear List I am extremely sorry for off the topic question. I am willing to buy nano3G Nodeb. Is anyone in list have spare which can be sold. Please let me know. -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243 <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

4 3

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

Google Summer of Code 2019
by Vadim Yanitskiy 12 Mar '19

12 Mar '19

Dear Osmocom community, starting from 16th of January (until 7th of February) we can apply Google Summer of Code as an Open source mentor organization. Many well-known projects, such as Debian, FFmpeg, Apache, Git, GCC, GNURadio and others, have been participating last year. Personally, I think it's a great opportunity to move some of our projects forward. I would like to know your opinions about this idea, should we participate? I would be happy to be a mentor. With best regards, Vadim Yanitskiy.

6 13

LimeNET Micro
by Keith 06 Mar '19

06 Mar '19

The new product from Lime is marked to start shipping tomorrow. As far as I understand it is basically the LimeSDR mini with a GPS disciplined clock and a Raspberry Pi module, so it /should/ run osmo-bts + osmo-trx-lms fine, and without clocking issues. It also has POE. I was wondering if anybody else has looked at it, has comments, or has or is thinking of ordering one? Thanks!

3 3

static strings -- little fun on the side
by Neels Hofmeyr 04 Mar '19

04 Mar '19

As a bit of relaxation in-between the serious hacking, I gave a little idea of mine a spin, which could improve our use of static string buffers. My idea is to use one common static buffer string, as a ring buffer, for all our osmo_xxx_name() functions, that returns new chunks of static string every time. Why? The point is that we have many osmo_xxx_name() functions that return a string in one single static buffer. When you call it a second time, it overwrites the buffer. So this doesn't work: printf("PLMN changed from %s to %s\n", osmo_plmn_name(old_plmn), osmo_plmn_name(new_plmn)); No matter what, this will always print the same string twice, and probably no-one would notice. For this, I have previously often invented xxx_name2() functions: printf("PLMN changed from %s to %s\n", osmo_plmn_name(old_plmn), osmo_plmn_name2(new_plmn)); With osmo_plmn_name2() being: "Same as osmo_plmn_name(), but returning in a different static buffer." That is bad for these reasons: - each new separate function adds another static buffer to the program size, which remains unused all the other time. - each new separate function adds more API signatures. Alternatively we have xxx_buf() functions, but they are more cumbersome to use: char buf[123]; gsm0808_cell_id_list_name_buf(buf, sizeof(buf), cil); LOGP(DMSC, LOGL_DEBUG, "%s\n", buf); Particularly for logging, that would always run even though the logging category might be switched off. So I came up with these patches, and changing all of current libosmocore's static buffers to using this does work: http://git.osmocom.org/libosmocore/log/?h=neels/static_strings (second last patch introduces the API, last patch changes all libosmocore callers) Also pushed to gerrit for easier review: https://gerrit.osmocom.org/13061 the benefits: - All osmo_xxx_name() functions can be called N times in a single printf() statement, without the need for managing buffers. - No osmo_xxx_name2() functions for "separate static buffer" - Just fire off LOGP() args and the code gets skipped if the category / log level is switched off: LOGP(DMSC, LOGL_DEBUG, "PLMN changed from %s to %s, but Fred says it was %s\n", osmo_plmn_name(old_plmn), osmo_plmn_name(new_plmn), osmo_plmn_name(freds_plmn)); I think it would be nice to have this mechanism for easier string hacking, but not sure if the tradeoffs / vague side effects are worth it. So this might as well remain a fun idea that never made it. Thoughts welcome. Implementation considerations... At first I thought a plain ring buffer returning the next bit of memory every time would suffice, but I didn't like the need to vaguely trust that we never use overlapping memory. The best I could come up with was to guarantee up to N subsequent static strings as non-overlapping. See the semantics around the 'recent' members. But that entails an uncomfortable tradeoff: I kind of expected to reduce the size of static char buffers in libosmocore, but if I want to disallow overlapping N uses, the buffer has to be able to hold N subsequent allocations of the largest buffer, which currently is 4100. So I end up with a larger static char buffer. The advantage however is that every libosmocore using program with its own xxx_name() functions can now use the same static string space and does not need to add more static buffers all over the place. To make the buffer smaller, I considered taking the largest buffer callers out of this, i.e. osmo_hexdump() and msgb_hexdump(). But particularly osmo_hexdump() is one of the functions that I would like to be able to call more than once in a printf() arg list. Actually that would in practice be of smaller size than the maximum 4096 currently allowed. But the 'recent' check above requires the *largest* size to fully fit N times. Consider: if I choose a total buffer of 4096 bytes and print one hexdump of 3084 bytes, then I can't print another such buffer: the osmo_static_string() function can't know that the first printf() has already concluded, and still considers that large chunk as in-use. So to be able to allow any number of subsequent printf()s of the same huge size, I need the number-of-recent-checks times that large size to fit in the static buffer. So there is a tradeoff between how many previous buffers I can guarantee to be unchanged vs. the maximum buffer size allowed per allocation. I would actually like to ensure 10 or more recent buffers, so that a caller can say: I can use up to 10 various osmo_xxx_name() functions in the same printf() statement, and libosmocore will barf if I use too much. I would also like to use less static char buffer -- but is ten times 4096 as static string buffer really a lot? Not for an x86_64 desktop machine, but what about embedded targets? Since in practice the name buffer sizes we use are more like <80 chars each, in practice we would be totally fine with one 4096 char buffer. I have never seen a hexdump of 4Kb in practice. I'm considering actually removing the 'recent' check again and just offloading the responsibilty for name buffer usage to the caller. Or I'm considering to reduce the max hexdump / msgb_hexdump size to something saner like 1024 chars or even 256 chars. (Actually, hexdump could also loop in chunks of 64 bytes or something like that). Another consideration was about how to effect bounds checking. I don't want to evaluate return values in printf() args. So I decided to provide generalized API that returns NULL pointers if the size did not fit, but for convenience use have one osmo_static_string() function that OSMO_ASSERT()s as soon as the size doesn't fit, instead. ~N -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC February 2019