OpenBSC July 2016

openbsc@lists.osmocom.org

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

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

Moving from trac to a single redmine
by Holger Freyther 25 Sep '16

25 Sep '16

Hi guys, I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now. Tickets: Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either: * not import tickets * only import from one project * deal with changing ticket numbers In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number? Wiki: We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this? kind regards holger

6 15

SS MM Messages (Call forwarding etc)
by Keith Whyte 15 Aug '16

15 Aug '16

Hi All, A few weeks ago, I wrote to the list about a handset that was opening and holding an lchan after doing IMSI attach. After some investigation I see this phone is querying the network for call forwarding status. This phone then cannot send any more USSD codes, or make calls, although it can receive, but for some reason insists on doing the query again after call termination. Doing the same from other handsets, by dialling such codes as *#21# in each case gives the same result of eternal lchan usage, although some (more modern) phones seem to eventually timeout, releasing the channel while others do not. I connected numerous phones and did the same on each one and pretty soon I have a kind of DOS situation on the network in that SDCCH is at capacity. The last log message resulting from the request is /openbsc/openbsc/src/libmsc/gsm_04_08.c:3586 Dispatching 04.08 message, pdisc=11 although strangely with one phone, this is followed shortly by: libosmocore/src/gsm/gsm0480.c:219 USSD Request is too short. openbsc/openbsc/src/libmsc/ussd.c:55 Unhandled SS so for that one phone, it would seem handle_rcv_ussd() is being called from gsm0408_dispatch() I have been going through the code, basically adding more debug output to try to verify what is being called from where, and I also found the functionality in libosmocore such as gsm0480_decode_ss_request(), although this is not called at anytime from the nitb. This is an enormous project! I notice these lines in openbsc/openbsc/src/linmsc/gsm_04_08.c in gsm48_rx_mm_serv_req() /* we will send a MM message soon */ conn->expire_timer_stopped = 1; It would seem that we don't ever send this MM message. It's not clear to me where I might try to check again on the status of this MM request, or if the problem is a lack of full implementation of these supplementary service requests. Would anybody be interested in working on this with me? Keith.

2 5

[PATCH] remove INSTALL file to have a clean git status
by Neels Hofmeyr 08 Aug '16

08 Aug '16

From: Neels Hofmeyr <neels(a)hofmeyr.de> The INSTALL file is being overwritten by autoreconf, but it is committed as empty file. As a result, the INSTALL file always shows as modified. Instead, remove INSTALL from git and ignore it. --- .gitignore | 1 + INSTALL | 0 2 files changed, 1 insertion(+) delete mode 100644 INSTALL diff --git a/.gitignore b/.gitignore index e15c19b..d1a0b33 100644 --- a/.gitignore +++ b/.gitignore @@ -39,6 +39,7 @@ libtool ltmain.sh missing stamp-h1 +INSTALL # vim *.sw? diff --git a/INSTALL b/INSTALL deleted file mode 100644 index e69de29..0000000 -- 2.1.4

3 4

signal quality measurements in osmo-trx
by Max 04 Aug '16

04 Aug '16

Hi. I'm working on http://projects.osmocom.org/issues/1616 and wonder about $subj. In case of sysmobts, osmo-pcu obtain this data directly from DSP: * RSSI (dBm) * burst timing (in quarter of bits) * link quality (in dB) * BER The first and last value seems to be easy from what I see in src/osmo-bts-trx/scheduler_trx.c What about burst timing (necessary to compute TA in the absence of PTCCH) and link quality (measure of C / I where C is carrier and I is interference power) - how can I compute those or some estimator to those values? -- 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 5

Re: OsmoNITB + Asterisk
by Anonim Stefan 31 Jul '16

31 Jul '16

Hi, Is there any intention / interest among current community developers to implement the DTMF for osmo sip connector?! Thanks, Stefan On Jul 27, 2016 3:33 PM, "Holger Freyther" <holger(a)freyther.de> wrote: > On 27 Jul 2016, at 20:19, Brian Butterly <bbutterly(a)ernw.de> wrote: > > Hi, Hi! > has anyone recently put together a functional setup with OsmoNITB and > Asterisk (+LCR)? why asterisk? why LCR? The osmo-sip-connector is a "trivial" piece of software that bridges MNCC to SIP (and back) and let's everyone else do the heavy lifting. In contrast to LCR it currently lacks: * Multi-party calls (a bit harder) * DTMF (quite easy but not done) holger

2 1

OsmoNITB + Asterisk
by Brian Butterly 30 Jul '16

30 Jul '16

Hi, has anyone recently put together a functional setup with OsmoNITB and Asterisk (+LCR)? I've got multiple errors while compiling LCR with Asterisk, mainly unknown definitions and a set of missing functions. My setup: -NanoBTS -current OpenBSC (running perfectly) -Ubuntu Xenial, 64Bit, VBox VM -current LCR from Osmocom Repos -Asterisk (build without any issues) --1.8.32.3 from Asterisk Page --1.6.2.24 from Asterisk Page --11.32.0 form Asterisk Page --last 13.x release vie apt I had expected the newer versions to be incompatible, still gave them a shot anyways. I've started fiddling with LCR, but before I go deeper into that, I just wanted to check if there was some defined approach which would get everything up and running. I'd be very thankful for any hint or maybe some information on which versions of what will actually work together. Thanks! Brian

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2016