OpenBSC September 2016

openbsc@lists.osmocom.org

19 participants
25 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

MS cannot connect; Location Update Request not received by BTS?
by Bruce Smith 10 Nov '16

10 Nov '16

5 7

Re: Profiling data of decoding EPDAN compressed bitmap
by Holger Freyther 29 Oct '16

29 Oct '16

> On 13 Jul 2016, at 12:21, Max <msuraev(a)sysmocom.de> wrote: > Hi all, > After looking at the code, I don't think reusing table implementation > would be easy - the approaches are too different as well as underlying > data structures. okay. then we will need to use the tree based version and from my point of view we should do it the following way: * Remove osmo_t4_decode (and related routines) from libosmocore (last step) * Make the tree based decoder ready in terms of the surrounding style * Adopt/Clone the osmo_t4_decode tests and move them to the PCU (as part of the commit that adds the decoder to the PCU) @Me: After the infrastructure is in the PCU I will remove osmo_t4_decode (and tests) from libosmocore @Radisys: I am afraid the tree based decoding is not ready yet and as it impacts the upcoming encoder (and other RLE code as far as I understand) let me put it here. In osmo-pcu (and all other projects) we use libtalloc for memory allocations. This means the tree should use talloc with proper parent/child allocations. This way the destructor of the decoder will also free all nodes of the tree. There should be no call to malloc/free in the PCU. Please take the tests from libosmocore and make sure they work with the new decoder. Tests are the lifeline and we need more and not less of them. The decoder needs to be robust against invalid input. search_runlen can fail but the caller doesn't check for that. Please test with invalid/truncated or broken inputs to see we don't end in a never terminating while loop. Test using unit tests. Similar the current osmo_t4_decode can return an error that is propagated back to the compressed bitmap decoding and we should have the same. Reduce code duplication. With the decoder the only difference between the if/else is if the data is filled with 0x00 or 0xFF and which table/root to use. Instead of having code clones please parameterize either by having local variables in the beginning or by calling different (inline) functions. kind regards holger

1 1

multiple phy with osmo-trx
by Max 13 Oct '16

13 Oct '16

Hi! I've asked about it before but this seems to have been lost in communication. The question is basically how to enable multi-TRX support for osmo-bts-trx using phy/instance infrastructure similar to other bts? What I've tried so far is documented in http://projects.osmocom.org/issues/1648 but it did not result in working setup yet. In short, I'd like to configure OpenBSC with 1 BTS with 2 TRX, each with its own arfcn and set of channels. I'm running "osmo-bts-trx -t 2" and correspondingly "osmo-trx -c 2" on usrp b210. Any ideas on what's missing to make this actually work are greatly appreciated. -- Max Suraev <msuraev(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

4 15

Re: OsmoBTS -> libosmogsm code migration
by Vadim Yanitskiy 11 Oct '16

11 Oct '16

Hi Max, Thanks for your reply! > I think extending utils/conv_gen.py is the way to go because it will > allow us to have concise description of the convolutional codes in one > place and as close to the description in standards as possible. Ok, I will keep your opinion in my mind. > Could you specify which files exactly are you referring to? Also you can > use 'git blame' to clarify authorship. No problem, they are: - gsm0503_conv.c - gsm0503_interleaving.c - gsm0503_mapping.c - gsm0503_parity.c - gsm0503_tables.c Almost all the gsm0503_*, excluding the 'gsm0503_coding.*'. Thank you for this hint, this command is very usable! :) > I don't think library functions should do any sort of logging by itself > (unless it's a logging functions of course :) > Instead they should return clearly distinguishable values and let caller > do the logging as they see fit. I am agree with you. It's time to use return codes. Have a nice day! With best regards, Vadim Yanitskiy.

6 17

coverity for osmocom projects
by Neels Hofmeyr 03 Oct '16

03 Oct '16

Today, I've taken a quick look at the coverity stuff, because so far I've only seen coverity reports on the Iu code. I see now that actually all of the other osmocom components are also tested by coverity. So far I'm only seeing the "Osmocom" coverity project, which contains only the iu build. In fact that's a bit of a misnomer -- I assumed that "Osmocom" would contain all of the osmos, it should be more like 'Osmocom-3G' or 'Osmocom-Iu'. The other osmos are in coverity projects named "libosmocore", "osmo-bts", etc: https://scan.coverity.com/projects?utf8=%E2%9C%93&search=osmo I see there are "add me to project" buttons e.g. here https://scan.coverity.com/projects/libosmocore so I'm trying that now. Wouldn't it make sense to redirect all the coverity reports to a mailing list? Probably best would be a new mailing list, to avoid noise on openbsc@, like the gerrit-log@ list. Are these coverity reports a matter of secrecy, to avoid publishing security holes before we fixed them, in which case the coverity mailing list should be invite-only? ~Neels

3 6

Query on run time control of network with VTY
by Dhananjay kumar 01 Oct '16

01 Oct '16

Hi, While ruining osmo-bts and osmo-trx via VTY we tried to change parameter like Band ,ARFCN MS max power. We observed that once ARFCN is changed on VTY TRX does not switch to new ARFCN. Same behavior has been observed with Band and MS-Max-Power and RF-Locked 0/1 parameter. Request someone who is running osmo-stack has controlled network ,please reply or any document/pointer is appreciated. BR Dhananjay

4 6

osmo-sip-connector issue
by Anonim Stefan 30 Sep '16

30 Sep '16

Hi, I am using osmo-nitb + osmo-sip-connector and I am sending INVITE to it, as in the attached trace. The connector replies with 0.0.0.0 RTP IP and 0/unknown codec and then ends the call. I am seeing the following log: " Sep 23 09:08:00 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> mncc.c:334 call(1073741832) can not be found Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0002> app.c:104 Unknown ptmsg(0). call broken Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> mncc.c:312 leg(5001) rtp connect failed Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> sip.c:245 Ending leg(0x91ec30) in con Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> mncc.c:304 leg(1073741832) can not be found Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> sip.c:186 leg(0x91ec30) got bye, releasing. " This issue happens *after* *recently* *updated* *packages* to: " ii osmocom-nitb 0.15.1.20160922 amd64 GSM Network-in-a-Box, implements BSC, MSC, SMSC, HLR, VLR ii osmo-sip-connector 1.20160922 amd64 MNCC to SIP bridge for osmo-nitb " On the osmo-nitb side I am seeing logs [1]. I suspect a bug in the osmo-sip-connector code. Can someone confirm this? [1] http://pastebin.com/giG0HHha

2 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC September 2016