OpenBSC January 2023

openbsc@lists.osmocom.org

5 participants
20 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 08 Jul '25

08 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

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

01 Feb '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

Call for Help: Test data from SIM cards for pySim-shell decoder unit tests
by Harald Welte 30 Jan '23

30 Jan '23

Hi all! I'm currently adding unit tests for the various pySim encoder/decoder classes for the variouus SIM/UICC/USIM/ISIM files. [1] In order to increase the test coverage, I would appreciate any help in obtaining test data, particularly for the more "exotic" (or recently introduced) files, related to DF.5GS, ADF.ISIM or even DF.WLAN or the like. So if you have any SIM cards with related files populated, I would appreciate some test data. You can simply send me a copy+paste of the respective 'read_binary' / 'read_records' command, or a partial 'export'. In the latter case, please make sure to redact/remove your IMSI/ICCID/MSISDN/Kc data to prevent leaking privacy related information. Thanks in advance. Regards, Harald [1] https://gerrit.osmocom.org/c/pysim/+/24012 -- - Harald Welte <laforge(a)gnumonks.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Phones jumping ship from commercial networks to test network
by Mychaela Falconia 24 Jan '23

24 Jan '23

Hello GSM community, I have a question for those who operate their own GSM networks (be it for fun or for research or for any other purpose) in places that DO have regular commercial cell service, i.e., NOT ship-at-sea, middle of desert or Rhizomatica-type environments: how do you deal with, and ideally prevent, the highly undesirable situation of other people's phones, not related to your operation, "jumping ship" from being registered to their regular commercial network to trying to register to your test network instead? I live and operate in an area where ONE commercial operator still provides GSM/2G service (although only to "grandfathered" customers, closed to new subscribers), plus there are super-strong 4G and 5G signals from all 3 USA-wide carriers. I also operate my own "pirate" GSM network on a test/experimental basis, meaning not always on, but only turned on for brief intervals when I am playing with it. When I do turn on my test GSM network, I squat on an ARFCN in the middle of a 5 MHz wide "dead" spot (SA shows noise floor over the whole 5 MHz block in question), and most of the time I set my power output to the lowest possible setting: I set max_power_red to the maximum of 20, which should result in 3 dBm output from the sysmoBTS box. I also recently changed my MCC-MNC from 310-222 (an unallocated MNC within MCC 310) to 001-325 (MCC meaning test network, MNC is a feeble attempt to indicate that it's me - I got 00440325 as my test IMEI range in my "other" capacity as ME manuf), but the problematic behaviour of at least some phones erratically "jumping ship" from T-Mobile GSM to the test network still occurs. Here is a concrete example of inexplicable erratic behaviour I am seeing: * Last night I powered up my test network at around 19:41 local time. My wife was with me the whole evening; her primary personal phone is Nokia C3-00 (circa 2011, late in GSM terms, but still 2G-only in terms of RAN support) with service on T-Mobile. * About 3.5 hours later, at around 23:14 local time, my wife noticed that her phone "went into the black hole" (our term for times when phones show "no service" even though T-Mobile GSM signal is there just fine), and she alerted me. I looked at OsmoCNI logs in syslog, and I saw that just a little earlier, at around 22:38 local time, there was an attempt from my wife's phone (her T-Mobile IMSI) to register to our test network. Of course that registration attempt failed - I don't have a roaming agreement with T-Mobile, there is no MAP roaming support in OsmoCNI, I don't have any T-Mobile or other operators' IMSIs in my OsmoHLR, and I am NOT running with "create sub on demand" feature. * At around 23:14 local time, when my wife noticed that her phone went into the black hole, she immediately proceeded to reboot it - such reflexive reboots are now an "autopilot" action for her - and on its next boot cycle, it immediately proceeded to make another attempt to register to our test network instead of T-Mobile, as evidenced by OsmoCNI logs! * At that point I turned off the test network GSM signal, as there did not appear to be any other way to convince my wife's Nokia phone to go back to its rightful network of T-Mobile. Now let me add some noteworthy details: * The ARFCN on which I squat for my test network is NOT listed in the neighbor cell list advertised by the sole and single commercial GSM/2G operator we have around here. * When I mentioned this issue previously in an OsmoDevCall USSE, I was asked if perhaps the ARFCN I squat on might be listed as a 2G neighbor in the neighbor list of some newer-G cell. I don't have any direct way to disprove this idea, but my wife's phone, the one that exhibits this inexplicable behaviour, is a 2G-only model, NOT supporting LTE or even UMTS. And the last 3G/UMTS service in our area was shut down last summer, leaving only LTE+5G for the masses and GSM for the tiny sliver of "grandfathered" users who won't give it up until we die. * In last night's episode, my wife's phone sat quite happily within our dwelling, mere meters from the sysmoBTS antenna putting out its 3 dBm, for almost 3 hours before it made its first attempt to jump ship. During the entirely of this almost-3-hours interval, the signal from our test network as received by the phone was overwhelmingly stronger than the commercial signal (being meters away from the BTS), yet the phone behaved like it should (listened to its serving cell and advertised neighbor cells, no searching around) for almost 3 h. * The location update interval set by T-Mobile's network is 1 hour - thus periodic LU could not have been the trigger that told Nokia's bugger to abandon its serving cell and go into open-ended search of all possible ARFCNs. So what in the world could have been the trigger then, that caused the bugger to misbehave after almost 3 hours of behaving properly and correctly? * Aside from whatever the trigger might be, once that Nokia bugger attempts to register to the test GSM network and fails, why in the bloody hell is it not going back to the weaker (in terms of RSSI) but working T-Mobile network, why does it "park" itself in no-service state instead? I have heard of other people operating test GSM cells/networks in areas where commercial services do exist: I have heard that Neels, of Sysmocom team, operates a test cell under a test license, and when Keith gave an OsmoDevCall presentation on Rhizomatica back in 2021, that presentation was done from an office in some "big" city in Oaxaca, a place where test signals had to coexist peacefully with commercial operators' signals. So how do you guys do it? What additional magic are you doing, which I must be missing, to prevent the situation of phones jumping ship from commercial networks to the test network when the signal from the test network is much stronger due to proximity? Perplexed, Mother Mychaela

2 2

GCR (osmo_store16be/osmo_store32be)
by Keith 19 Jan '23

19 Jan '23

Hi All, I was working a few months back on some LCLS implementation with bts-loop and I got it working, including that the pbx can use SIP Re-INVITES to get in and out of the audio loop during calls. However, I only ever tested it with one call, that is with two phones. When I tested it on alive site, immediately there where problems so I reverted and left it. Looking at it again now, there's a very obvious problem which is that osmo-msc generates the same GCR for (almost) every call. I had noticed this before but for some reason I thought I had seen it generating different GCR for a second simultaneous call, but no. Anyway, the above is extraneous info to the question: Could somebody take a look at this: https://gitea.osmocom.org/cellular-infrastructure/osmo-msc/src/branch/maste… where we have: osmo_store32be(trans->callref, lcls->gcr.cr); osmo_store16be(use_lac ? trans->msc_a->via_cell.lai.lac : trans->msc_a->via_cell.cell_identity, lcls->gcr.cr + 3); Now, If I change the order, such that would seem logical: osmo_store16be(use_lac ? trans->msc_a->via_cell.lai.lac : trans->msc_a->via_cell.cell_identity, lcls->gcr.cr + 3); osmo_store32be(trans->callref, lcls->gcr.cr); Then I get a different GCR, reflecting the trans->callref for each call. But am I then maybe overwriting the LAC/CI ? Would seem to make sense, but I'm just not sure if that is all there is to it, as I don't really grok osmo_store_xxxx for(i = 0; i < n; q[i] = (x >> ((n - 1 - i) * 8)) & 0xFF, i++); Is it just a simple order error, and is everything OK with lcls->gcr.cr + 3 as the pointer *p passed to osmo_store32be_ext() ? given that: struct osmo_lcls *lcls; where: struct osmo_lcls { struct osmo_gcr_parsed gcr; }; struct osmo_gcr_parsed { uint8_t cr[5]; }; I guess I'm still not really 100% on the char/uint8_t thing and advancing pointers. Thanks! k.

2 2

OsmoDevCall on Jan 18, 2023: ice40-usbtrace OSHW USB protocol tracer
by Harald Welte 18 Jan '23

18 Jan '23

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: January 18, 2023 at 20:00 CET where: https://osmocom.org/OsmoDevCall This time, @tnt will be presenting on ice40-usbtrace OSHW USB protocol tracer In case you never heard about ice40-usbtrace before: It's a low-cost full-speed USB protocol tracer built around the iCE40 FPGA. This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation as outlined above 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you soon! Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Distributed GSM
by Keith 18 Jan '23

18 Jan '23

Hi all, I was thinking about how to deal with the so called "evil twins" in the distributed hlr, and also how to have a subscriber-create-on-demand situation at the same time as a having an mslookup client. The problem being that if we have mslookup client + fallback to create-on-demand if no HLR responds for an IMSI, we will eventually create a duplicate because the HLR that owns the IMSI is not contactable at the time of an IMSI ATTACH attempt. Anyway, just in terms of investigating the situation on my HLRs, I added features [1] - so far, an ability to do a gsup.hlr lookup and not exit on the first age:0 - so that I can see all HLRs that respond as having the imsi in local HLR, and also to ask via mDNS for HLRs that have an IMSI, but only if it's active on that HLR, that is, it has nam_cs/nam_ps So this is really asking about what people feel about expanding the D-GSM features in osmo-hlr, as I think it may be the case that rhizomatica/TIC are the only people that use it? [1] https://gitlab.tic-ac.org/rhizomatica/osmo-hlr

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2023