OpenBSC September 2018

openbsc@lists.osmocom.org

20 participants
27 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

Save the Date: OsmoCon 2018 on October 18-19, 2018
by Harald Welte 19 Oct '18

19 Oct '18

== OsmoCon 2018 == OsmoCon (Osmocom Conference) 2018 is the technical conference for Osmocom users, operators and developers! We are happy to announce the date of OsmoCon 2018. It has been scheduled on October 18 + 19, 2018 and will happen in Berlin, Germany. For the second time, the Osmocom Conference brings together users, operators and developers of the Osmocom Open Source cellular infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN and others. Join us for two days of presentations and discussions with the main developers behind Open Source Mobile Communications, as well as commercial and non-profit users of the Osmocom cellular infrastructure software. You can find some initial information in our wiki at http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018 which will be updated as more information becomes available. == Call for Participation == We're also at the same time announcing the Call for Participation and call on everyone with experiences to share around the Osmocom member projects to submit talks, workshops, discussions or other proposals. You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp We are particularly looking for contributions about: * updates on features/functionality/status of individual Osmocom projects * success stories on how Osmocom projects are deployed in practice * migration from OsmoNITB to the post-NITB architecture * tutorials / workshops on how to setup / analyze Osmocom projects * statistics, reporting, operations aspects of Osmocom projects * third-party open source utilities to be used with Osmocom projects Looking forward to meeting many existing and new Osmocom users at OsmCon this October! Regards, Harald Welte -- - 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)

3 4

Re: LimeSDR-USB experience with New Splits Solved!
by Vadim Yanitskiy 06 Oct '18

06 Oct '18

> Are you referring to the ones from 2015 or so with > Russian titles? Those are the only ones I am aware of Yes. There are few. Check out this one: https://youtu.be/jw-63aOOPk0 > how do you know that phone was running against an > Osmocom network [...] I know the author. Also, you can see the logs of OpenBSC on the background of the mentioned video. > The relation is simple: if phones like Mot C1xx running > Motorola's original factory fw don't work with Osmocom > networks, [...] In order to confirm, I just tested a Motorola C118 running the original firmware with Osmocom-based network. LimeSDR-Mini was used as PHY for OsmoTRX. Everything works fine, including: SDCCH: SMS, USSD, other signaling TCH/H: both HR and AMR codecs TCH/F: FR, AMR and EFR codecs Probably, the author of this topic has some problems with codec / network configuration. With best regards, Vadim Yanitskiy.

2 1

Trace needed: AMR voice call signalling on SCCP in AoIP network
by Philipp Maier 25 Sep '18

25 Sep '18

Hello Folks, I am trying to resolve some open questions about the encoding of the AMR codec configuration bits S0-S15. (see also 3GPP TS 48.008, 3.2.2.103, "The coding of Speech Codec Element for FR_AMR, HR_AMR and OHR_AMR:" and 3GPP TS 28.062, Table 7.11.3.1.3-2) Since I do not have any AoIP network that I could trace against to verify that all my assumptions about the coding of those bits are correct I would love to see a trace from some other network. It would be kind if anyone of you could help me out with that. All I need is a trace from a call. It is important that AMR is negotiated in the Assignment request. best regards, Philipp Maier -- 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

Re: Build failure of network:osmocom:nightly/simtrace2 in xUbuntu_18.04/x86_64
by Neels Hofmeyr 24 Sep '18

24 Sep '18

These build failures are continuously piling up in my inbox. Would it make sense to either fix or disable it? ~N On Sat, Sep 22, 2018 at 08:01:31PM +0000, OBS Notification wrote: > Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/s… > > Package network:osmocom:nightly/simtrace2 failed to build in xUbuntu_18.04/x86_64 > > Check out the package for editing: > osc checkout network:osmocom:nightly simtrace2

2 2

CBSP protocol traces wanted / wireshark dissector
by Harald Welte 19 Sep '18

19 Sep '18

Hi! I recently wrote a wireshark dissector for the CBSP protocol, which is a 3GPP standard for the interface between the Cell Broadcast Centre and the BSC. It's specified in 3GPP TS 48.049 in case you're curious. The dissector can be found at https://code.wireshark.org/review/#/c/29745/ However, I couldn't find any protocol traces to verify the dissector against. So if you happen to have done any work on cell broadcast in 2G network and have a CBSP trace around (or can generate one): Please send it to me, thanks! If I ever find the time, I'd love to add CBSP support to OsmoBSC, and even to go one step further and write a minimal CBC itself. Contributions are of course always welcome, in case there are other interested folks. 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

CBCH support for osmo-bts-trx
by Lorenzo Cavallini 19 Sep '18

19 Sep '18

Hello everyone, I was going to add support for CBCH to osmo-bts-trx for a project, then just by chance I looked at this ticket: https://osmocom.org/issues/1617 and I've seen that the issue was reopened 13 days ago. Any chance on getting some pre-pre-pre-alpha patch? I would gladly test and work on it in whatever state the code is now, still better than starting from scratch. Thanks for the awesome work anyway! Best regards, Lorenzo

3 15

Jenkins build is back to normal : Coverity-Upload (jenkins-job-builder) #240
by jenkins＠lists.osmocom.org 19 Sep '18

19 Sep '18

See <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/240/display/redire…>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC September 2018