OpenBSC November 2022

openbsc@lists.osmocom.org

11 participants
15 discussions

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

cmd2 update causing pySim-shell to fail
by bryan coxwell 24 Jun '25

24 Jun '25

Hi all, Just wanted to share an issue and a quick workaround I found for it in case anyone else has the same problem. I believe a cmd2 update is causing pySim-shell to fail. After installing it on a fresh install of Ubuntu Server 20.04 and getting the following error when I run "python3 pySim-shell -p0": >Using PC/SC reader interface >Autodetected card type: sysmoUSIM-SJS1 >AIDs on card: > USIM: a0000000871002ffffffff8907090000 >Traceback (most recent call last): > File "pySim-shell.py", line 512, in <module> > app = PysimApp(card, rs, opts.script) > File "pySim-shell.py", line 59, in __init__ > super().__init__(persistent_history_file='~/.pysim_shell_history', allow_cli_args=False, use_ipython=True, auto_load_commands=False, command_sets=basic_commands, >startup_script=script) >TypeError: __init__() got an unexpected keyword argument 'use_ipython' If you run into this you can fix it by uninstalling cmd2 and reinstalling cmd2 with "pip3 install cmd2==1.5". Best, Bryan

5 5

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

libosmocore/BSC/MSC: MO voice calls rejected from Siemens S11E (patch included)
by Lennart Müller 31 Jan '24

31 Jan '24

Hi, I had a problem placing MO GSM calls from a Siemens S11E: The calls were dropped immediately; Osmo-MSC reports "Cannot compose Channel Type from bearer capabilities" After investigating the SETUP request from the S11E, the phone does not use octet 3a (no extension bit set in IE 3). Wireshark decodes the radio channel requirement as "Full rate support only MS/fullrate speech version 1 supported", so I added a condition to the gsm48_ie.c function of libosmocore to include at least GSM FR in the list of available speech_ver in case octet 3 has no extension. Attached to this message are the Abis-IP PCAP traces of MO calls, and the patch for gsm48_ie.c. Regards, Lennart

6 6

Problem while running NIB on Open Cellular Base sation
by Brackley Casinga 31 Jan '24

31 Jan '24

Hi, My name is Brackley Cassinga Form DRC, we run a community network called pamoja net where we offer gsm services using osmocom open source software and OC Base station. Recently I have tried to install another base station as the same installed but I could not find any resource guiding through all the steps to take to run NIB on a base station. I'm currently running Ubuntu and I will appreciate if you could guide me on the installation of BSC,hlr,MSC , in order to run a basic gsm network. Thank you. Regards -- *Ir Brackley heshima Casinga **Pacifique* *CEO and Founder of kwanzatechnologie* KwanzaTechnologies ,GlobalElectronics +243977265291 | +243977265291 | Pcassinga(a)gmail.com/ brackley(a)ensemblepourladifference.org www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> | Skype: Brackley cassinga <https://webapp.wisestamp.com/#> Av Semliki N 43

2 1

Representing BFI in an RTP stream in FR & EFR modes
by Mychaela Falconia 28 Nov '22

28 Nov '22

Hello GSM community, As I keep working on my project seeking to build a new GSM network that will be no worse in every aspect than the one which T-Mobile USA are itching to shut down, I need a way to ferry the uplink voice stream from the BTS to my "soft TRAU" in RTP transport, but do it in a way that is semantically no-worse than what happens in the traditional T1/E1-based architecture. As part of this no-worse-than-TDM desire or requirement, I need explicit BFI markers - in other words, any time there is a 20 ms window in which there is no good traffic frame to be sent because the uplink is in DTX, because that frame was lost to bad radio conditions or because that frame was stolen for FACCH, I want my BTS to send an explicit BFI frame instead of gapping/pausing the RTP stream. But this "simple and innocent" desire which I just expressed then turns into a perplexing question: just how would one represent an explicit BFI marker in an RTP stream? In the case of AMR codec there is a straightforward solution already provided for in the specs: simply send a NO_DATA frame. But what about FR and EFR codecs? For my own Themyscira Wireless deployment, I currently run with my own non-standard extension to RTP transport format for FR & EFR, documented here: https://www.freecalypso.org/hg/themwi-system-sw/file/tip/doc/RTP-BFI-extens… My solution works great for my purposes, and I am very happy with it. However, in the spirit of seeking at least some unity and at least some chance of patches being merged, I am making a due-diligence attempt to understand how others have addressed similar problems, and what competing solutions may already exist out in the wild. Here is my specific question to the community, mostly the narrower Osmocom community but perhaps also the wider GSM community: where did the idea of an all-zeros frame representing BFI come from? In the current osmo-bts-trx implementation (although not in any other osmo-bts variants that I can see from the code) there is code that sends an FR codec frame of 260 zero bits or an EFR codec frame of 244 zero bits, both intended to signal BFI, under the following conditions: 1) The BFI condition exists for some reason other than the uplink being in DTX, i.e., because the frame was stolen for FACCH or was lost to radio errors, but the last frame was not a SID; and 2) There is no ECU on the channel, or the ECU failed to provide a substitute frame. Irrespective of specific conditions though, the key point is that someone, somewhere, at some point in time had the idea that an FR or EFR codec frame of all zeros (260 or 244 zero bits, respectively) should mean BFI. There is also a patch to gapk by Vadim, adding an FR codec EFU function, that detects a frame of all-zeros and treats it as BFI - but I am not able to tell if the very idea of such BFI representation comes from Vadim, or if Vadim simply added the code to gapk to work with what osmo-bts-trx puts out under certain conditions. To put the question differently: does there exist any spec from ETSI or from 3GPP or from any other non-Osmocom standards body that defines an FR codec frame of 260 all-zero bits and/or an EFR frame of 244 all-zero bits to mean BFI, or is this idea a pure Osmocom invention? The only official specs I could find for coded speech transport within RAN, between a BTS and a separate transcoder, deal with the traditional T1/E1 environment, as in GSM 08.60 and friends. In those specs BFI is signaled out of band: in GSM 08.60 TRAU frames there is a control bit carrying BFI, and another control bit carrying TAF (important for traditional Rx DTX handlers for FR & EFR), both outside of 260 data bits, and there is NO special bit pattern (all zeros or otherwise) within data frame bits themselves that would also signal BFI. Therefore, based on what I see in GSM 08.60 and other specs for T1/E1 world, I get the idea that BFI is meant to be an out-of-band signal, not in-band, and that an in-band bit pattern that signals BFI seems to go against the spirit of ETSI and 3GPP. But maybe the problem is that I was only looking at older specs, maybe there is some newer spec from 3GPP or some other standards body written for the newer world of IP transport that officially repurposes in-band all-zeros FR and EFR codec frames to mean BFI - is there any such spec? Moving from the realm of rhetorical questions to the realm of tangible code, here is my latest creation in the realm of GSM codecs: https://www.freecalypso.org/hg/gsm-codec-lib/ I will make another announcement when this code reaches the level of completeness I am after, but as a short summary, I am making a librified (turned into a library) version of the official EFR codec implementation from ETSI (libgsmefr), and I have also written another library of my own (libgsmfrp) that implements Rx DTX handler functions for GSM FR, to be run as a pre-processor before passing frames to a GSM 06.10 decoder, which is typically gsm_decode() from libgsm. libgsmfrp is already integrated into my "soft TRAU" implementation in themwi-mgw, and libgsmefr will likewise be integrated when it is complete. (Right now only the decoder works in libgsmefr, the encoder remains to be finished.) Both libgsmefr and libgsmfrp have BFI handling functions which the "soft TRAU" application needs to call when it receives a BFI marker instead of a good traffic frame, but the question of how these BFI markers should be represented in an RTP stream is outside the scope of the library - instead my themwi-mgw application currently implements ThemWi RTP-BFI-extension and calls the respective library functions. I may be open to the possibility that I should not be inventing my own RTP-BFI-extension and should instead use in-band frames of all-zeros to represent BFI in FR & EFR, *if* there is some official spec from 3GPP etc saying so - but if that idea is an Osmocom invention rather than 3GPP, then I am going to argue for my invented alternative RTP representation instead. So which is it? With devotion to GSM Forever, (Hasta la Victoria, Siempre,) Mother Mychaela

2 2

eNodeB to offer
by tsaitgaist 26 Nov '22

26 Nov '22

I have a complete eNodeB (LTE base station) to offer, with following components: - 1x Ericsson DUL 20 01 (the base station) - 1x Ericsson RUS 01 B4 (80W RF fronted for LTE band B4) - 1x Mean Well RS-150-48 (48V 3.3A power supply for both above) - 2x power input cable (for DUL and RSU, based on RPM 777 193/00315 R1B cable connector) - 1x spare power 20A cable (RPM 77 193/00315 R1B) - 1x mini SPF cable (to interconnect DUL and RSU, RPM 777 211/00900) - 2x coaxial cable to inter-connect RSU to its cavity block (RPM 777 701/00050, 1x on RSU, 1x spare) - 3x coaxial to SMA cable (RPM 777 227/00080, for RSU RXA I/O, RXA OUT, RXB I/O ports) - 1x USB to RS232 adapter, for DUL terminal port - 1x RS-232 to RJ45 adapter, for DUL terminal port - 2x 26mm RF connector to N connector adapters (for RUS RF A and B port) - 2x N to SMA adapters - 1x N termination (10W) - 1x SMA termination (<1W) - 1x alternative OS (on compact flash card, with different configuration/licenses) - 1x N-connector antenna (antenna size is 35 cm, 698-960 + 1700-2700 MHz) - 1x SMA cable antenna (antenna size is 30 cm, 688-960 + 1700-2700 MHz) - 1x N-connector cable antenna (antenna size is 10 cm, flat PCB antenna, 700-2600 MHz) you can have all of that for free, as long as you take care of the shipping (12 kg, from Germany). if you are interested, just let me know.

1 0

linking local libs in C tests
by Neels Hofmeyr 21 Nov '22

21 Nov '22

Hi all, I am having an automake / libtool problem and don't know how to solve it. In libosmo-pfcp, there is the pfcp_test binary, which obviously requires linking libosmo-pfcp.so -- more precisely, it should NOT link the system installed libosmo-pfcp.so, but the locally built one, libosmo-pfcp.a. I try to accomplish this by: pfcp_test_LDADD = \ $(LIBOSMOCORE_LIBS) \ $(top_builddir)/src/libosmo-pfcp/libosmo-pfcp.la \ $(top_builddir)/src/libosmo-gtlv/libosmo-gtlv.la \ $(NULL) https://cgit.osmocom.org/libosmo-pfcp/tree/tests/libosmo-pfcp/Makefile.am I am now adding a new optional IE to libosmo-pfcp, and I found that this does not work as expected! The pfcp_test binary is linked to the previously installed libosmo-pfcp.so in /usr/local/lib, instead of the proper, new version from the build tree. I found out by getting an obscure ABI corruption error, verified it by: ~/osmo-dev/make/libosmo-pfcp/tests/libosmo-pfcp $ ldd .libs/pfcp_test [...] libosmo-pfcp.so.0 => /usr/local/lib/libosmo-pfcp.so.0 (0x00007f1b6bc00000) libosmo-gtlv.so.0 => /usr/local/lib/libosmo-gtlv.so.0 (0x00007f1b6cc0a000) [...] As soon as I 'make uninstall' in libosmo-pfcp.git's root dir, this changes to: ▶ ldd .libs/pfcp_test [...] libosmo-pfcp.so.0 => not found libosmo-gtlv.so.0 => not found [...] and then the test succeeds (because './pfcp_test' is actually a shell script generated by libtool with linker magic referencing the libs built within the libosmo-pfcp.git tree). Now I am at a loss: How do I tell automake (libtool) to keep out the system installed .so and prioritize the libs in the build tree? I can work around this for me by doing 'make uninstall' every time the libosmo-pfcp ABI changes, but I would much rather fix this, so that users rebuilding a newer version pulled from git don't run into this obscure problem. I suspect that we may have a similar pitfall in many other osmo source trees, because the Makefile.am *looks* like it takes care of this problem, but actually doesn't. Any ideas? I am using: automake (GNU automake) 1.16.5 autoconf (GNU Autoconf) 2.71 libtoolize (GNU libtool) 2.4.7 (Debian Unstable) Thanks! ~N

3 4

java applet loading on sysmo-isim-sja2
by Philipp Maier 21 Nov '22

21 Nov '22

Hello Folks. I am trying to get my head around on how java applet loading works for sysmo-isim-sja2. At first I used the following, updated example to compile a HelloSTK2.cap: https://github.com/mrlnc/HelloSTK2.git This works fine and it also loads fine on sysmo-usim-sjs2 using shadysim.py Now I want to load the exact same file to a sysmo-isim-sja2. I tried with shadysim_isim.py from https://github.com/herlesupreeth/sim-tools: ---------------8<--------------- $ python shadysim_isim.py --pcsc 2 -l /home/owner/work/simcard_applet_loading/HelloSTK2.cap -i /home/owner/work/simcard_applet_loading/HelloSTK2.cap --enable-sim-toolkit --module-aid d07002ca44900101 --instance-aid d07002CA44900101 --nonvolatile-memory-required 0100 --volatile-memory-for-install 0100 --max-menu-entry-text 15 --max-menu-entries 05 --kic 56B6B26346DEF2A74BC8DFAF3BEA71D6 --kid 8EFE5A4B60C751FD18F33A24886967E7 Traceback (most recent call last): File "shadysim_isim.py", line 494, in <module> ac.load_app(args.load_app) File "shadysim_isim.py", line 369, in load_app self.load_aid_raw(aid, data, len(data) / 2) File "shadysim_isim.py", line 271, in load_aid_raw self.send_wrapped_apdu_checksw('80e60200' + ('%02x' % (len(data) / 2)) + data + '00c0000000') File "shadysim_isim.py", line 246, in send_wrapped_apdu_checksw raise RuntimeError("SW match failed! Expected %s and got %s." % (sw.lower(), response[1])) RuntimeError: SW match failed! Expected 9000 and got 6985. ---------------8<--------------- And I also tried with gp.jar from https://github.com/mrlnc/HelloSTK2.git ---------------8<--------------- $ java -jar ./gp.jar --key-enc 56B6B26346DEF2A74BC8DFAF3BEA71D6 --key-mac 8EFE5A4B60C751FD18F33A24886967E7 --key-dek 3BA47E883FE2462B5D43B85C4CCDF0AC --install /home/owner/work/simcard_applet_loading/HelloSTK2.cap [main] WARN pro.javacard.gp.PlaintextKeys - Don't know how to calculate KCV, defaulting to SCP02 [main] WARN pro.javacard.gp.PlaintextKeys - Don't know how to calculate KCV, defaulting to SCP02 [main] WARN pro.javacard.gp.PlaintextKeys - Don't know how to calculate KCV, defaulting to SCP02 [main] INFO pro.javacard.gp.GPSession - Using card master keys: ENC=56B6B26346DEF2A74BC8DFAF3BEA71D6 (KCV: 1ADB2F) MAC=8EFE5A4B60C751FD18F33A24886967E7 (KCV: 174546) DEK=3BA47E883FE2462B5D43B85C4CCDF0AC (KCV: D7011A) for null [main] INFO pro.javacard.gp.GPSession - Diversified card keys: ENC=56B6B26346DEF2A74BC8DFAF3BEA71D6 (KCV: 1ADB2F) MAC=8EFE5A4B60C751FD18F33A24886967E7 (KCV: 174546) DEK=3BA47E883FE2462B5D43B85C4CCDF0AC (KCV: D7011A) for SCP02 [main] INFO pro.javacard.gp.GPSession - Session keys: ENC=76900ED8B816F1822A29D7DC81F1B843 MAC=02D74CFFA5F85F1F999F23F60C22AF02 RMAC=87AFE7F26DDE69307EA35AE567AC8F26, card keys=ENC=56B6B26346DEF2A74BC8DFAF3BEA71D6 (KCV: 1ADB2F) MAC=8EFE5A4B60C751FD18F33A24886967E7 (KCV: 174546) DEK=3BA47E883FE2462B5D43B85C4CCDF0AC (KCV: D7011A) for SCP02 CAP loaded Error: INSTALL [for install and make selectable] failed: 0x6A80 (Wrong data/incorrect values in data) ---------------8<--------------- As it seems gp.jar seems to work better than shadysim_isim.py. Unfortunately I have no experience in java card programming yet, so its difficult for me to tell where the error could be. (When I run gp.jar once more it tells me "Error: STRICT WARNING: Package with AID D07002CA44 is already present on card", I can also delete the applet again, so apparently its kind of loaded...) Is there anyone here who managed to load an applet to a sysmo-isim-sja2 and how? best regards. Philipp -- Philipp Maier <pmaier(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 * Geschaeftsfuehrer / Managing Director: Harald Welte

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2022