OpenBSC September 2017

openbsc@lists.osmocom.org

26 participants
56 discussions

ctrl interface: GET a variable with parameter
by Neels Hofmeyr 28 Sep '17

28 Sep '17

Yesterday I noticed that apparently we are unable to GET a variable with argument, e.g. in OsmoHLR get the ps-enabled status of a subscriber and passing the subscriber's IMSI along for the value we'd like to receive. Experimenting a bit, I found that for GET commands, any tokens sent after the variable name are ignored, dropped on the floor and cause neither an error nor are evaluated. With a tiny patch, we can make passing arguments to GET parameters optional: https://gerrit.osmocom.org/4069 But notably, by adding some CTRL parsing tests I found some interesting behavior... https://gerrit.osmocom.org/4067 https://gerrit.osmocom.org/4068 In OsmoHLR, such a status request is so far implemented as a SET, since SET takes an argument and also returns a result. See: https://gerrit.osmocom.org/4062 (patch obsolete after 4069) For that particular set of commands in OsmoHLR: enable-ps <IMSI> (WO) disable-ps <IMSI> (WO) status-ps <IMSI> (semantically RO, nevertheless a SET, so technically WO) I thought it would also make sense to just have one variable for the whole lot, as in subscriber-enable-ps <IMSI>,<val> (RW) so that we reflect that single value with a single CTRL variable. After all, that's how the CTRL API appears to be intended: GET and SET commands on the same entity, instead of blowing up each variable by op * value range. Or even a command to query and change various subscriber values: subscriber <IMSI> <variable>[=<val>] [<variable>[=<val>] [...]] (RW) e.g. GET 1 subscriber 123456789087654 msisdn msc_nr imeisv reply: subscriber 123456789087654 msisdn=12345 msc_nr=1 imeisv=123456789abcdef SET 1 subscriber 123456789087654 msisdn=54321 msc_nr=4 imeisv=fab123434843823 reply: OK or: "Cannot modify msc_nr, nothing changed" or: "Unknown subscriber parameter: xyz" One step further would be to pick an identification trait from imsi, msisdn or imei... GET 1 subscriber imsi=123456789087654 msisdn imeisv GET 1 subscriber msisdn=12345 imsi imeisv GET 1 subscriber imeisv=12345abcdef123 imsi msisdn (often a new subscriber in communal networks can easily find the phone's IMEI, where the IMSI is unknown, so queries like this would be useful in general) Would this be too much of a monster command? Rather: GET 1 subscriber-by-imsi 123456789087654 msisdn imeisv GET 1 subscriber-by-msisdn 12345 imsi imeisv GET 1 subscriber-by-imeisv 12345abcdef123 imsi msisdn Comments welcome! ~N -- - Neels Hofmeyr <nhofmeyr(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 * Geschäftsführer / Managing Directors: Harald Welte

4 5

pySim inconsistent on seemingly identical SIM cards
by Billy Jones 28 Sep '17

28 Sep '17

I have two SIM card I inheritted from a previous project that I've been told came from the same vendor. When I run `pcsc_scan` on them, I get the following output for both: Reader 0: OMNIKEY CardMan (076B:3022) 3021 00 00 Card state: Card inserted, ATR: 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68 ATR: 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68 + TS = 3B --> Direct Convention + T0 = 7D, Y(1): 0111, K: 13 (historical bytes) TA(1) = 94 --> Fi=512, Di=8, 64 cycles/ETU 62500 bits/s at 4 MHz, fMax for Fi = 5 MHz => 78125 bits/s TB(1) = 00 --> VPP is not electrically connected TC(1) = 00 --> Extra guard time: 0 + Historical bytes: 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68 Category indicator byte: 55 (proprietary format) Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68 SIM from sysmocom sysmoSIM-GR2 When I try to program one of the SIMs, it works fine: $ sudo ./pySim-prog.py -p 0 -i 001010000000001 -k ffffffffffffffffffffffffffffffff -t sysmoSIM-GR2 --num=1 --mcc=001 --mnc=01 Insert card now (or CTRL-C to cancel) Generated card parameters : > Name : Magic > SMSP : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000 > ICCID : 8901001010000000017 > MCC/MNC : 1/1 > IMSI : 001010000000001 > Ki : ffffffffffffffffffffffffffffffff > OPC : f134b55cea2942ebbd213c82e084be62 > ACC : None Programming ... Done ! But on the other I get: $ sudo ./pySim-prog.py -p 0 -i 001010000000001 -k ffffffffffffffffffffffffffffffff -t sysmoSIM-GR2 --num=1 --mcc=001 --mnc=01 Insert card now (or CTRL-C to cancel) Generated card parameters : > Name : Magic > SMSP : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000 > ICCID : 8901001010000000017 > MCC/MNC : 1/1 > IMSI : 001010000000001 > Ki : ffffffffffffffffffffffffffffffff > OPC : 53945a5223e299bf6cec05911922442c > ACC : None Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 636, in <module> card.program(cp) File "/home/user/workspace/pysim/pySim/cards.py", line 382, in program self._scc.verify_chv(0x05, pin) File "/home/user/workspace/pysim/pySim/commands.py", line 111, in verify_chv return self._tp.send_apdu_checksw(self.cla_byte + '2000' + ('%02X' % chv_no) + '08' + fc) File "/home/user/workspace/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 9840. I also tried some of the other branches, as people on other forums had reported better luck with those, but I get the same error. Is there any documentation explaining the magic byte values that are sent back and forth to the card? I'm having a hard time understanding the spec by which the program is trying too communicate with the card. Any help is greatly appreciated. Thanks, Billy

2 3

"NITB split" and implications for OsmoSGSN
by Max 27 Sep '17

27 Sep '17

Hi. There's clearly big difference between split BSC/MSC and NITB (config files, support for SCCP-lite etc) which makes the transition rather lengthy. What about SGSN and related stuff? It's been transitioned to libvlr at the time of split as well, but does this transition have any user-visible consequences? If not than we could transition gradually: * make SGSN build optional (--enable-gprs?) in openbsc repo * start building OsmoSGSN from osmo-sgsn repo instead of openbsc (both .deb and OE) * test and make sure that it works the same way (both on sysmobts and on debian) * disable SGSN build by default and announce that patches should be made against new repo * remove gprs code from openbsc leaving placeholder readme with the link to new repo All the steps above are unrelated to BSC/MSC items so it could be done independently. -- 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

3 4

osmo-bts Installation issues
by Ron 26 Sep '17

26 Sep '17

Hi All, We installed osmo-bts-trx using Debian 9 OS through nightly package and encountered an error after running it. As per checking, there is an existing bug in osmo-bts regarding the "osmobts-trx: error while loading shared libraries: libosmotrau.so.1: cannot open shared object file: No such file or directory” error. https://osmocom.org/issues/2481 So we tried to install it through building it from source. Upon installation, we encountered an error upon running ./configure. Error message: checking whether to enable support for sysmoBTS L1/PHY support... no checking whether to enable support for osmo-trx based L1/PHY support... no checking whether to enable support for Octasic OCTPHY-2G... no checking whether to enable NuRAN Wireless Litecell 1.5 hardware support... no checking for openbsc/gsm_data_shared.h... no configure: error: openbsc/gsm_data_shared.h can not be found in /root/osmo-bts/../openbsc/openbsc/include So we tried to rename the gsm_data.h found in “~/osmo-bts/include/openbsc” folder to gsm_data_shared.h. The ./configure goes through but has an error upon running "make”. Is there another way to install osmo-bts? Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

1 0

Error in doing apt-get install in Debian 9
by Ron 26 Sep '17

26 Sep '17

2 2

Building openBSC in Ubuntu 14.04 kernel 3.19
by Anindya Sankar Roy 22 Sep '17

22 Sep '17

Hello, I have gone through some of the documentations and now trying to install osmoBSC i.e just the BSC part not the openBSC or osmoNITB. I am kind of confused , can anyone please tell me if I can build just the BSC part and in order to do that what are the packages that I have to configure. Thanks Anindya

3 7

request for gerrit votes to fix debian packages
by Neels Hofmeyr 22 Sep '17

22 Sep '17

To fix the osmo-msc preliminary debian package build of osmo-msc, I need these patches in osmo-mgw to be merged: https://gerrit.osmocom.org/3999 https://gerrit.osmocom.org/4000 https://gerrit.osmocom.org/4001 https://gerrit.osmocom.org/4002 https://gerrit.osmocom.org/4003 https://gerrit.osmocom.org/4005 (topic 'new_mgw' less 4006 and 4007) If review takes too long I am tempted to just merge it ahead to fix the state of osmo-msc.deb in https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly If I do, it means that I would like to fix and improve those patches later, not that I want to smuggle them past review. I just want to finally get the debian builds working and off my mind again. The osmo-msc currently fails because it needs a header file not included in libosmo-mgcp-client-dev, because that is still tied to libosmo-mgcp headers, which are of course not included in the libosmo-mgcp-client deb. I want them to be separated completely to save us this kind of cumbersomeness in the future. Only one of the above commits unties libosmo-mgcp-client from the other libs, but small bits here and there make the change depend on the others in that bunch. I could re-arrange, but that would take time. I'd rather just keep them in that order, we want them merged anyway. The large ones in the middle are dexter's work on the next generation MGW that happened on a branch, being placed beside the legacy code. This way we can move from legacy to new code in osmo-msc and osmo-bsc independently. ~N

2 3

API versions vs. release versions
by Neels Hofmeyr 22 Sep '17

22 Sep '17

It seems there are a lot more versionings around than I thought... I am currently deciding on how we want to handle libtool API versions. These are strings of the form current:revision_of_current:compat_age MGCP_LIBVERSION=5:23:4 means that - We are in API version 5. - This is the 23rd "small internal" modification of 5. - We are backwards compatible to 4 previous API versions (1 thru 5). This is not at all related to release versions of the major.minor.patch form. For example, each small tweak of the code will bump the middle 'revision_of_current' number, whether it's a minor or patch release bump. Now I had the plan to actually coincide the major release version with the API current version. When we are in release 1.0.1 thru 1.23.42 and so forth, keep the library API current version at 1. Once we do a major version bump to 2.0.0, we can go on to API current version 2. Coinciding seems to make sense because we anyway don't want to make API breaking changes unless we bump the major release number. BTW the API 'current' version number also appears in the debian package names like libosmo-mgcp2.deb and the installed library files, like libosmo-mgcp.so.2... Keeping the API current the same as release major makes sense to me, but only up to this point: when we add a new side feature to a library. When all of the library stays the same and is backwards compatible, and all we do is add a new function to it, someone linking against it may want to make sure that this new function is included in the installed version. So even if we don't bump a major release, don't break API and so forth, we may still want to increase the API-current version and bump the names of the debian packages as well as installed .so files. Why? Because if we had libosmo-mgcp1 and added function mgcp_frobnicate(), and we want to use mgcp_frobnicate() in osmo-msc.deb, we want to depend on a libosmo-mgcp that has it added, i.e. we bump to libosmo-mgcp2.deb and depend on that from osmo-msc.deb. All the while libosmo-mgcp's version tag still remains at 1.0.23, only the API version changed. This would be the libtool-intended way, and we'd see a lot of debian package names' numbers bumping, not at all related to our major-release, whenever we add any new function to our API. Only in reality, if I see libosmo-mgcp5.deb, as a user I do expect it to be libosmo-mgcp release 5.2.3, not release 1.0.23. Right?? Is that only me? According to libtool, coinciding the API version with the release version is abuse. OTOH it's what I actually expected for most of my life... :/ Will we have the discipline to bump API current for each addition? And bump each depending projects' debian depends-clauses? What do you guys think about this? See https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info… Thanks! ~N -- - Neels Hofmeyr <nhofmeyr(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 * Geschäftsführer / Managing Directors: Harald Welte

2 2

HEADS UP: stricter VTY, possible config fallout
by Neels Hofmeyr 22 Sep '17

22 Sep '17

Hi all, we have recently merged a profound change to the inner workings of the VTY configuration. We've hit some fallout due to that, hence I would like to let you know that you might hit the same. The VTY parsing of config files is now strict about indenting. A child node *must* be indented below the parent node, and indenting must be consistent. For more details on the reason why and a definition of 'consistent', see the commit log of https://git.osmocom.org/libosmocore/commit/?id=4a31ffa2f0097d96201f80305a04… So, if you are in the near future faced with config files being rejected that worked perfectly before, it is most probably because your indenting was wrong all the time, and only now did we start checking it. If the cause is hard to figure out, a good aid is the telnet VTY, where you may either 'show running-config' or traverse the nodes manually to query which command exists on which level. If your current config is broken, you may be able to start the program with an empty or stripped down config file to make its telnet available. The above is about reading config files, but we have also dropped the implicit 'exit' to parent level on the telnet VTY console. This caused fallout where nodes by plain omission lack the 'exit' command: one is unable to leave such a node once it is entered. That is a fault in the program's VTY setup that was not found before, because the VTY would often just find the parent node's exit command instead. I have a patch to avoid all of these everywhere, by installing the exit and end commands automatically for every VTY node that gets created; it is not merged yet: https://gerrit.osmocom.org/3998 ------ Config Fallout Example ------ For example, we hit a breakage with this osmo-bts-trx.cfg: phy 0 instance 0 osmotrx rx-gain 25 osmotrx tx-attenuation oml osmotrx ip local 10.23.42.1 osmotrx ip remote 10.23.42.2 Before, this worked perfectly. Now it says the command 'osmotrx rx-gain' does not exist. The reason is that 'osmotrx rx-gain' is a child node of 'instance 0'. The first fix looked like this: phy 0 instance 0 osmotrx rx-gain 25 osmotrx tx-attenuation oml osmotrx ip local 10.23.42.1 osmotrx ip remote 10.23.42.2 But alas, this time it said the command 'osmotrx ip local' does not exist. I suspected bugs in the new parsing, but indeed, 'osmotrx ip' is actually a direct child of the 'phy 0' level. Before, the VTY would implicitly step out of a child level if it found a matching command one parent above. That is confusing in other situations (see above commit log), hence we now require indenting to clarify the structure. This is the correct one: phy 0 instance 0 osmotrx rx-gain 25 osmotrx tx-attenuation oml osmotrx ip local 10.23.42.1 osmotrx ip remote 10.23.42.2 Or rephrased: phy 0 osmotrx ip local 10.23.42.1 osmotrx ip remote 10.23.42.2 instance 0 osmotrx rx-gain 25 osmotrx tx-attenuation oml To query the structure via telnet, I did: $ ./osmo-bts/src/osmo-bts-trx/osmo-bts-trx -c osmo-bts/doc/examples/trx/osmo-bts.cfg $ telnet localhost 4241 OsmoBTS> enable OsmoBTS# configure terminal OsmoBTS(config)# phy 0 OsmoBTS(phy)# list [...] osmotrx ip HOST osmotrx ip (local|remote) A.B.C.D [...] OsmoBTS(phy)# inst OsmoBTS(phy)# instance 0 OsmoBTS(phy-inst)# list [...] osmotrx rx-gain <0-50> osmotrx tx-attenuation <0-50> osmotrx tx-attenuation oml [...] ------ No Exit Example ------ The same osmo-trx VTY nodes also show the exit failure: $ telnet localhost 4241 OsmoBTS> enable OsmoBTS# configure terminal OsmoBTS(config)# phy 0 OsmoBTS(phy)# exit % Unknown command. OsmoBTS(phy)# instance 0 OsmoBTS(phy-inst)# exit % Unknown command. On the phy level, we would previously find the parent's 'exit' command, but in the 'instance' level, 'exit' has never been available. Above patch should fix all of these. ~N -- - Neels Hofmeyr <nhofmeyr(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 * Geschäftsführer / Managing Directors: Harald Welte

3 3

Osmo-trx build problem
by mohammad nejati 21 Sep '17

21 Sep '17

Hi , i’m trying to build osmo-trx master branch . What i’am doing : autoreconf -i ./configure make In make step i get this error : Evaluating ‘parse’ option: ‘(?P\d+).(?P\d+).(?P\d+)’ does not parse current version 'P2.8TRUNK’ usage: bumpversion [-h] [–config-file FILE] [–verbose] [–list] [–allow-dirty] [–parse REGEX] [–serialize FORMAT] [–search SEARCH] [–replace REPLACE] [–current-version VERSION] [–dry-run] --new-version VERSION [–commit | --no-commit] [–tag | --no-tag] [–tag-name TAG_NAME] [–message COMMIT_MSG] part [file [file …]] bumpversion: error: the following arguments are required: --new-version make all-recursive

3 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC September 2017