OpenBSC July 2018

openbsc@lists.osmocom.org

15 participants
21 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

The magic behaviour of 'logging level all LEVEL'
by Vadim Yanitskiy 30 Aug '18

30 Aug '18

Hi all, A discussion was started during the review of https://gerrit.osmocom.org/10116/. The main idea of this change is to fix the behaviour of 'logging level all LEVEL', but I think it was also mixed with some additional feature, which I would like to discuss here, publicly. First of all, the change introduces a new special logging level 'unset', which allows one to reset a given category (i.e. unset its custom value): !! Initial logging configuration: logging level all error logging level mncc debug logging level pag notice logging level meas debug !! Resetting DMNCC: # logging level mncc unset !! So, now DMNCC has no custom log level, it will use !! the default level (in this example it is 'error'): logging level all error logging level pag notice logging level meas debug This feature looks fine and extremely useful for me. But (among fixing) this change additionally changes the behaviour of a command for setting the default logging category (i.e. 'logging level all LEVEL'): !! Initial logging configuration: logging level all error logging level mncc debug logging level pag notice logging level meas debug !! Changing the default logging level: # logging level all debug !! Ahhh, I've lost my custom levels :( logging level all debug !! What I expected to get: logging level all debug logging level mncc debug logging level pag notice logging level meas debug So, together with changing the default logging category, this command now would also reset all custom settings... I am not sure this is exactly what one need/expect, so I would like to share the following ideas: 1) The category 'all' looks/sounds confusing when it's used in such cases like this: # logging level all debug because one can interpret it like: "set all categories to debug". despite actually (according to the implementation) this is related to the default logging policy. Maybe, we should rename it to 'default'? So, 'logging level all LEVEL' would *set all categories* to a given logging LEVEL, while 'logging level default LEVEL' would only affect the default logging level... 2) Introducing the new command: # logging level unset LEVEL which is intended to assign a given LEVEL to all categories, which have no custom logging level (i.e. have 'unset'), would make the idea of having default logging policy meaningless. Setting logging level(s) for all possible categories (using this command), looks like writing iptables rules for all possible and impossible cases instead of using the DEFAULT policy... 3) The introduced behaviour of resetting all categories to 'unset' could be implemented in a separate function, and can be represented by a separate command: # logging level unset-all The name of this command clearly defines the expected behaviour. Moreover, it doesn't affect the default logging level, which can be still changed by a separate command. As we (me and Pau) have different opinions, or we simply don't understand each other, let's make this discussion public, and let's see what others think about this... With best regards, Vadim Yanitskiy.

5 25

Cell Broadcast Feature
by Ron 31 Jul '18

31 Jul '18

Hi Community, Does anyone tried to use the Cell Broadcast feature in osmo? https://osmocom.org/projects/cellular-infrastructure/wiki/Cell_Broadcast Is there specific SDRs that supports this feature? Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

2 2

Re: Cell Broadcast Feature
by Vadim Yanitskiy 31 Jul '18

31 Jul '18

Hi Ron, > Does anyone tried to use the Cell Broadcast feature in osmo? > Is there specific SDRs that supports this feature? I have not tried personally, but I would like to clarify one thing. CBCH is implemented in the higher *software* layers, so it doesn't depend on a specific SDR device. The problem is that it isn't (yet) implemented for osmo-bts-trx, a BTS variant for SDR devices... Moreover, I believe it should be quite easy to implement this, so any patches are welcome ;) With best regards, Vadim Yanitskiy.

2 1

Rationale behind ipa_ccm_idtag_parse_off() ?
by Harald Welte 31 Jul '18

31 Jul '18

Hi Holger, I'm getting back to the following libosmocore commit introduced in 2015: > commit f558ed4bb9c0f00997b8f97c2b251a574c1a64c4 > Author: Holger Hans Peter Freyther <holger(a)moiji-mobile.com> > Date: Tue Jun 2 15:52:06 2015 +0200 I can see what you are doing, but I have absolutely no idea as to why. AFAICT, the IPA CCM ID TLVs have the following structure: * 16bit length field * one byte tag * optional payload The length field *includes* the tag, so the actual payload length is the value encoded in the length field minus one. This means that the existing/classic ipa_ccm_idtag_parse() always returns one byte too much for the length of the IPA payload. I'm trying to address this in https://gerrit.osmocom.org/#/c/libosmocore/+/10216/ Your commit introduces ipa_ccm_idtag_parse_off(), which introduces a noffset field. However, that offset is used not only to compute the actual "payload" size, but it's also used for computing the subsequent CCM information elements. Hence, I cannot use any non-zero offset to parse a CCM blob. I also don't see any of our code using the ipa_ccm_idtag_parse_off() function, except the test case - where the test case seems to use a different encoding as seen on the wire, i.e. it uses only a single-byte length field. So if the function was just added for that test case, why not structure the data used in the test to reflect the on-the-wire protocol reality? There must be some genius rationale behind it, but I'm unable to figure it out. Maybe you still remember? Thanks! -- - 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)

2 5

4G / LTE and osmocom
by Ruben Undheim 30 Jul '18

30 Jul '18

Hi, The OpenBSC tools have turned into an impressive collection of tools. It is great to see this huge effort being done successfully! I was searching around on the osmocom site for information about LTE. Either, I am very bad at searching, or there is not so much information about that subject. I was wondering about the plans for LTE, if there are any such plans? I am writing this taking into account that in the country where I live, the major telecom providers plan to shut down the 3G infrastructure already next year, leaving only 2G and 4G running. In some years, they also want to shut down 2G (which I have heard has already been done some places across the Atlantic) I found a few other projects related to LTE: nextepc [1] and srsLTE [2]. I see that nextepc has been mentioned in a thread related to OsmoDevCon 2018, but I cannot see so much more information. Is the plan maybe some time to incorporate srsLTE and nextepc into osmocom infrastructure? Is there currently any cooperation? Or will there be some new and fresh LTE code in osmocom? Mainly, I was just wondering whether you can shed some light on / discuss this subject. Thank you very much. Best regards Ruben Undheim [1] https://github.com/acetcom/nextepc / http://nextepc.org/ [2] nhttps://github.com/srsLTE/srsLTE.git

3 2

Reflashing ip.access nano3G
by Ernesto Sanchez 25 Jul '18

25 Jul '18

Hello, I bougth one ip.access nano3G in ebay, it seem to have a custom firmware for an operator that does not work in my country I want to know how to reflash it with the correct firmware to run openbsc. Can anybody help me? Best regards and a lot of thanks in advance.

4 10

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2018