OpenBSC February 2020

openbsc@lists.osmocom.org

8 participants
9 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

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

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

D-GSM merge / open question on GT vs. IPA name
by Harald Welte 26 Feb '20

26 Feb '20

Hi Neels, some week[s] ago, you mentioned that the D-GSM merge is blocked around the question on how the Global Title vs. IPA-name is to be resolved. Sorry for not getting back any sooner, but I am simply not finding the required amount of time to investigate this topic at the moment. My personal opinion is that it should be a binary blob (buffer + length) and nobody should make any assumptions about the contents. This way we can store whatever we want in it, and I believe we're increasing possible use cases where our HLR would have to work with "stateless" translators between GSUP and MAP. After all, let's say we receive a LU from a subscriber roaming in MAP-land, then that request arrives with the GT of the MSC/VLR. If we can natively "digest" such values, then the translator would not require any state beyond the currently processed transaction (LU/ISD). If we can not, then the translator would have to keep long-term state such as tables to map MAP-GT to IPA name or the like. And that's of course more effort there, and volatile state that you'd need to synchronize in case of high availability or fail-over scenarios, etc. I of course also know none of this is any current use case that any of the sysmocom customers is funding sysmocom (and hence you) to spend time on. So in the end, I'll leave it to you to decide. If you think the effort for becoming "buffer+length" aware is relatively minimal (let's say up to two days?) then by all means, implement that. If you think it's more work, then please go for the faster route of not considering non-NUL-terminated strings as identifiers for "GSUP" peers. In any case, I am happy to merge the D-GSM patch series once you think it should be merged. I put it in your trusted hands. After all, we had a tagged release only 7 commits ago (well, 5 of those are actually already D-GSM related) in osmo-hlr, and should there be any fall-out from the merge, we still have quite some time until some new tagged release will happen a few months down the road. Thanks! 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

Commercial MSs do not see the network
by Tomcsányi, Domonkos 16 Feb '20

16 Feb '20

Hi All, I have been dealing with a weird issue in the past couple of days. I needed to quickly check something about some phones, therefore I created an Osmocom CNI based 2G network. I have done this multiple times in the past even with OsmocomBB transceiver, however in the past some years I was not active in 2G, was more focused on 4G. I was very happy to see, that all familiar things I initially liked about osmocom are still in place/improved a lot (meaningful config files, simple VTY interface, a LOT more and better documentation). So the network is up and running fine, the setup consists of a laptop and a USRP B210 without GPSDO. Then I tried to attach some phones to it, and hit an issue: * Samsung S6, S7 - does not detect the network, even if I put in a SIM card that has previously been in a phone that was already attached * iPhone X - does not detect the network I first fiddled with the power settings, basically trying to turn it down a little bit (initially tx attenuation was at 0, so I turned it 10-20), because range is not needed, but I know distortion can happen when driving SDR HW to its max capacity. No change in the above. Then I turned quickly to gr-gsm and rtl-sdr to see if I'm transmitting properly, the network was detected and C0 decoded properly. Next I tried with a Motorola C115 (yeah, I still have some lying around :)), and it attached to the network without any issue. Finally something that works as expected, right? Last but not least I tried with a Nokia 4.2 phone, which also attached to the network immediately without any issue. So the bottom line is: what could cause this behavior? Is it possible that the USRP B210's accuracy is just not enough for newer phones? If yes how come the Nokia still attached, it is quite a recent phone with Qcomm chipset. I was also thinking if it is a Samsung vs Qualcomm thing, but then the iPhone should have at least detected the network. I tried with different SIM cards as well (not that it would make any difference...but I didn't have any better idea), and also with different bands and ARFCNs (900 and 1800). Antenna used is a VERT900. Configuration: unmodified standard config that came with the binary packages - except for MCC, MNC, rx gain, tx attenuation and max_power_red. I also tried to specify valid and also 'invalid' (unknown) MCC-MNC combinations to see if maybe newer Android/iOS only lists networks that advertise a known combination (again this would be very weird, but I just had no better ideas in the end). Anybody have any recent experience with COTS MSs and OsmoBTS(-TRX) based network? Any input is much appreciated, thanks. Cheers, Domi p.s. It is simply awesome to experience the power of opensource when dealing with 2G. Every step of the way above I was using software created and shared by you guys. It is a great feeling, had to share it :-).

5 8

CBS + ETWS + CMAS + Limesdrmini
by Radiarisainana Sitraka 13 Feb '20

13 Feb '20

Hi, I follow this tutorial : Version 10 - History - Cell Broadcast - Cellular Network Infrastructure - Open Source Mobile Communications for doing CBS with limesdrmini but it doesn't run , is it due to that limesdrmini doesn't support the command telnet to osmo-bsc at port 4242, and enter something likeor i do something wrong. Chears, | | | | Version 10 - History - Cell Broadcast - Cellular Network Infrastructure ... Redmine | | |

2 1

Re: OpenBSC Digest, Vol 64, Issue 2
by Radiarisainana Sitraka 13 Feb '20

13 Feb '20

The commercial MS see the network and i could send sms and call with it. the Limesdrmini doesn't support CBS? Le mercredi 12 février 2020 à 20:57:52 UTC, openbsc-request(a)lists.osmocom.org <openbsc-request(a)lists.osmocom.org> a écrit : Send OpenBSC mailing list submissions to openbsc(a)lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request(a)lists.osmocom.org You can reach the person managing the list at openbsc-owner(a)lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. CBS + Osmocom + LimeSDR-Mini (Radiarisainana Sitraka) 2. CBS + ETWS + CMAS + Limesdrmini (Radiarisainana Sitraka) 3. Re: Commercial MSs do not see the network (Tomcs?nyi) 4. Re: Commercial MSs do not see the network (Joachim Steiger) ---------------------------------------------------------------------- Message: 1 Date: Wed, 12 Feb 2020 19:12:17 +0000 (UTC) From: Radiarisainana Sitraka <radiarisainanasitraka(a)yahoo.fr> To: "openbsc(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org> Subject: CBS + Osmocom + LimeSDR-Mini Message-ID: <647375309.3679103.1581534737485(a)mail.yahoo.com> Content-Type: text/plain; charset="utf-8" Hello, I'm testing CBS LimeSDR-Mini with osmocom by following this Version 10 - History - Cell Broadcast - Cellular Network Infrastructure - Open Source Mobile Communications | | | | Version 10 - History - Cell Broadcast - Cellular Network Infrastructure ... Redmine | | | h4. make sure your related BTS is configured to use a channel combination with CBCH For using a combined CCCH with SDCCH/4 and CBCH you can use the following example snippet as part of osmo-bsc.cfg: network bts 0 trx 0 timeslot 0 phys_chan_config CCCH+SDCCH4+CBCH

1 0

CBS + Osmocom + LimeSDR-Mini
by Radiarisainana Sitraka 12 Feb '20

12 Feb '20

Hello, I'm testing CBS LimeSDR-Mini with osmocom by following this Version 10 - History - Cell Broadcast - Cellular Network Infrastructure - Open Source Mobile Communications | | | | Version 10 - History - Cell Broadcast - Cellular Network Infrastructure ... Redmine | | | h4. make sure your related BTS is configured to use a channel combination with CBCH For using a combined CCCH with SDCCH/4 and CBCH you can use the following example snippet as part of osmo-bsc.cfg: network bts 0 trx 0 timeslot 0 phys_chan_config CCCH+SDCCH4+CBCH

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC February 2020