OpenBSC November 2018

openbsc@lists.osmocom.org

23 participants
30 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

voting in gerrit: merge at +3? (+2+1 / +1+1+1)
by Stefan Sperling 12 Dec '18

12 Dec '18

There has been some face-to-face discussion about Osmocom's code review process within sysmocom recently. I am posting to this list now with the consent of everyone involved so far, in order to involve the Osmocom community at large in this discussion as well. There has been a lack of code review from people who don't have "+2" super powers in Gerrit. This applies to anyone among us, independently of any individual's relationship with sysmocom. The bulk of the work involved in reviewing code falls on Harald's shoulders, with Pau and Neels sharing most of the rest between themselves. At present, while people who add a +1 have their voices heard, their input does not formally affect the decision to merge a change. A change still has to pass by the pre-selected +2 gatekeepers in order to be merged, no matter how many other people have provided input. The implication for developers without +2 powers is that their time is more effectively spent on advancing their own changes towards a +2 vote, rather than spending time on whatever else is waiting in Gerrit. This may not apply to everyone, of course. But at least for me, this is certainly the case; I have only been reviewing other people's patches when I was explicitly asked to do so. Myself and several other developers hope that with a change to our review process we can fix this inertia, spread code review across more shoulders and encourage more collaborative code review in Osmocom. The basic idea is that everyone's input should count for something. If those among us with +1 powers were given a partial say on the fate of every change, our decisions will carry more weight and our influence within the project will slightly increase. We'd also be encouraged to step out of our own corners of expertise every now and then, and look at what other developers are working on. On the flip side, this means we'd carry more responsibility than we do now. We wouldn't always be relying on our +2 gate keepers and would have to apply our own judgement more carefully. The concrete proposal is to make votes in Gerrit accumulative. Each change would require a total score of +3 to be merged. This score can consist of either a +2 and a +1 vote, or three +1 votes; and no -1 votes. Also, +2 developers would keep their ability to unilaterally block or revert changes under this new model. They'd keep their existing role as arbiters in case of disputes. Max figured out how Gerrit could be configured for this behaviour. It involves Prolog code, but since we're all quite smart we should be able to figure that out, right? https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html#_… We'd be interested to hear what the community thinks about this proposal. Thanks, Stefan

7 43

Info on Alcatel Femtocells
by Alex 29 Nov '18

29 Nov '18

Hi to everyone! I'm a new member and I really appreciate the work done here! I'm trying to use Alcatel Femtocells (ALU 9361/9362/9363) with osmo-hnbgw, but I'm still blocked at the IPSEC tunnel step. I've created an IPSEC server with EAP support, but I suspect there is a problem with my self signed certificate. Probably the femtocell has an internal trusted CA which validates server certs. I din't find the console pins on the board also, so I cannot simply connect to it and have a look at the system level. Has anyone any experience with this kind of HW or just an idea about a possible work around? Thank you and best regards Alex

2 6

HEADS UP: don't merge .adoc or vty ref changes to osmo-gsm-manuals.git anymore!
by Neels Hofmeyr 28 Nov '18

28 Nov '18

The adocs and vty reference content from osmo-gsm-manuals.git has been "moved" to the individual project repositories. That means if you apply more .adoc changes to osmo-gsm-manuals.git, we have to port that to the new location. (The content is not yet removed from osmo-gsm-manuals.git, so you might run into believing the move hasn't happened yet.) You can already edit in the individual osmo-bsc,-msc,... repositories, and build with 'configure --enable-manuals'. The jenkins publishing job isn't updated yet, should follow soon. right, osmith? ~N

3 4

osmo-gsm-manuals in project repos: I see no .pdf
by Neels Hofmeyr 28 Nov '18

28 Nov '18

Hi Oliver, so I merged the stuff to add the manuals to the individual git repositories, since you said that it works. But when I do --enable-manuals I don't see any PDF files generated. Also a manual 'make pdf' says "nothing to be done". (I probably should have tried it before merging after all) So what am I doing wrong? Alternatively, can you fix it please? ~N

2 2

nanoBTS fails to start with osmo-bsc
by Pierre Kim 26 Nov '18

26 Nov '18

With the newest git repo version of osmo-bsc, my nanoBTS fails to start. I can confirm that they work normally with ip.access softBSC. I thought osmocom Redmine issue #3063 might be relevant and tried setting/unsetting force-combined-si but I am still getting the same result. Attached are the packet capture and bsc config file The following is the log from osmo-bsc: <0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port 3002 <0004> abis_nm.c:847 OC=BTS(01) INST=(ff,ff,ff): GET ATTRIBUTE NACK <0004> osmo_bsc_main.c:178 BTS0 does not support Get Attributes OML message. <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[0/5]: 168a004 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[1/5]: 168a002 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[2/5]: 168a002 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[3/5]: 168a001 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[4/5]: 168a001 is v136d0 <0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is unreported <0004> abis_nm.c:2888 (bts=0,trx=0) IPA RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 <0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port 3003 <0003> osmo_bsc_main.c:283 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 600 using MCC-MNC 450-09 LAC=23 CID=0 BSIC=63 BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1149 **** ** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType ) ** IPA_SW_FATAL_ERROR ** In task "TRX Proc:L2_BCH" @ (325). **** . BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=TRX Proc:L2_BCH:l2_bch.c#1149 (325). BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31782:WARN:OAM_RES:trx_fatal_error_log.c#255:TRX has logged the error: . BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31782:WARN:OAM_RES:trx_fatal_error_log.c#256:TRX Proc:L2_BCH:l2_bch.c#1149 (325)

2 2

cellmgr-ng rotten (Re: Build failed in Jenkins: master-cellmgr-ng » a1=default,a2=default,a3=default,osmocom-master-debian9 #54)
by Pau Espin Pedrol 23 Nov '18

23 Nov '18

Hi all, I started looking at this failure and found out code in this repository is really old, with nobody maintain it (13 months since last commits?). I started by updating the contrib/jenkins.sh to use osmo-build-dep.sh and osmo-clean-workspace.sh like we do in other repos, because i felt it was not building up to date stuff. After updating that script, indeed it seems cellmgr-ng cannot be built against new libosmo-sccp due to some M3UA headers /API changes. There's even a tag during that commit in libosmo-sccp called "old_sua". After that commit, cellmgr-ng fails to build. If I try to build it against "old_sua", still cannot build fine with updated contrib/jenkins.sh script due to missing LIBOSMOSCCP_CFLAGS in tests/Makefile.am, and then still other headers are not found in other places, etc. I stopped at this point because I'm starting to spent too muhch time on this and it seems nobody is using it anyway. Can we disable the build of this project? Does somebody want to take care of it? Regards, Pau -- - Pau Espin Pedrol <pespin(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

2 1

SMS: UCS-2 concatenation with UTF16 emoticons
by Keith 20 Nov '18

20 Nov '18

Hi all, I noticed that SMS with emoticons on the boundary of the concatenated segments are not displaying correctly on the destination handset. * - imagine the disaster when that kiss-blowing smiley face thing at the end of your SMS turns out as a diamond with a ? for the recpipient! OMG, the potential butterfly effect is too much to think about... :)) So... This is my analysis: We have 140 bytes for the message, less the 6 bytes for the user header data in the case of concatenated SMS , leaving 134 bytes. It's well know that this means 67 characters per segment for an SMS using UCS-2 encoding. But, it we fill the message with emoticons that are using 4 bytes per 'character', then we have space for 134/4 = 33 and a half. Ooops. Still, the destination handset should reassemble the message and stick the two "halves" of the emoticon together, right? - except I'm not observing this. To rule out us doing something wrong in osmo, I wonder might somebody else (who has an unlimited SMS package) from a commercial provider try sending some crafted SM from one emoji-enabled phone to another, something like this: 😱abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123😱56789 That's likely going to get mangled by mailing list or your mua, so it is: [4 byte emoji]abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123[4 byte emoji]56789 You could also try various messages filled with emojis. Of course, if you bring up your osmo network with SMPP-mirror you can watch the trace in wireshark, you'll see when the last emoji gets chopped in two. You could try the same message on osmo and your commerical network. If it's actually a problem of the phones, you should get [4 byte emoji]abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123[two diamonds with ?]56789 Thanks! Keith.

4 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2018