March 2017 - OpenBSC - lists.osmocom.org

osmo-bts-trx channel activation
by Max 14 Mar '17

14 Mar '17

Hi. This has been asked last year but to no avail, let's try again. How logical channels are (de)activated in osmo-bts-trx? For example in all the other models there's sapi_deactivate_cb() callback but osmo-bts-trx doesn't seem to be using sapi_cmd at all. To put this into perspective - while working on https://projects.osmocom.org/issues/1575 I got to activate/deactivate lchans when SI3 is received. This already works for sysmobts but I'd like to do the same for osmo-bts-trx as well. Is there any documentation somewhere describing how it works there? Or maybe someone more familiar with the code could help to shed the light on it? -- 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

2 1

autoconf and .deb question
by Max 14 Mar '17

14 Mar '17

Hi. There's strange thing about the way autoconf and debian/rules interact for OpenBSC: - in openbsc/include/openbsc/Makefile.am gsm_data_shared.h and common_cs.h are in noinst_HEADERS - in debian/openbsc-dev.install they are marked for installation And this actually works! If you run "dpkg-buildpackage -uc -us -tc" you'll get openbsc-dev*.deb with those headers properly installed. It's nice but feels a bit too much like magic. Any ideas how dh_install (or smth else?) manages to work around it? Should we be worried that it might break some time in future? Should we move those headers away from noinst_* section? -- 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

2 1

IMSI: Inf ?
by Keith 14 Mar '17

14 Mar '17

This is a bit vague again... I have found across our sites several entries with a value of Inf for IMSI on a create-on-demand subscriber: For example: sqlite> select * from Subscriber where id=284054; 284054|2017-03-08 21:19:40|2017-03-08 21:19:40|Inf||20649|0||0| I also have some Inf values for IMEI in Equipment: sqlite> select id,created,imei from Equipment where id = 95108; 95108|2014-03-13 03:18:06|Inf Not a big deal for operations, just thought I'd mention it as I noticed while restoring backups, (sqlite3 doesn't like to reimport the Inf value it writes itself with .dump)

1 0

BS-11 Serial Interface
by Alexander Huemer 14 Mar '17

14 Mar '17

Hi, I have a Siemens BS-11 with the factory cable for the LMT that has a DSUB-9 plug on the non-BTS end. When I connect a USB<-->RS232 adapter and run either $ cu -l /dev/ttyUSB or bs11_config -p /dev/ttyUSB0 I do not get any output when I switch on the BTS. I tried with nullmodem adapter and without just to be sure since I often mix up the pinouts. I was not able to measure any voltage on any of the DSUB-9 pins when the BTS is powered up, but believe that on either RX or TX there should be the voltage level of the serial line since RS232 is active low. Has somebody seen this behavior? -Alex

2 1

FYI: Build failure of network:osmocom:nightly/osmo-pcu in xUbuntu_16.10/x86_64
by Neels Hofmeyr 13 Mar '17

13 Mar '17

fyi, we're still getting daily failures by the opensuse builds, which should be fixed once https://gerrit.osmocom.org/2007 is merged. ~N On Sat, Mar 11, 2017 at 07:57:26PM +0000, OBS Notification wrote: > Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o… > > Package network:osmocom:nightly/osmo-pcu failed to build in xUbuntu_16.10/x86_64 > > Check out the package for editing: > osc checkout network:osmocom:nightly osmo-pcu > > Last lines of build log: > [ 111s] from bts.cpp:21: > [ 111s] /usr/include/c++/6/cstdlib:185:3: note: candidate: __int128 std::abs(__int128) > [ 111s] abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; } > [ 111s] ^~~ > [ 111s] /usr/include/c++/6/cstdlib:180:3: note: candidate: long long int std::abs(long long int) > [ 111s] abs(long long __x) { return __builtin_llabs (__x); } > [ 111s] ^~~ > [ 111s] /usr/include/c++/6/cstdlib:172:3: note: candidate: long int std::abs(long int) > [ 111s] abs(long __i) { return __builtin_labs(__i); } > [ 111s] ^~~ > [ 111s] Makefile:778: recipe for target 'bts.lo' failed > [ 111s] make[2]: *** [bts.lo] Error 1 > [ 111s] make[2]: Leaving directory '/usr/src/packages/BUILD/src' > [ 111s] Makefile:403: recipe for target 'all-recursive' failed > [ 111s] make[1]: *** [all-recursive] Error 1 > [ 111s] make[1]: Leaving directory '/usr/src/packages/BUILD' > [ 111s] dh_auto_build: make -j1 returned exit code 2 > [ 111s] debian/rules:12: recipe for target 'build' failed > [ 111s] make: *** [build] Error 2 > [ 111s] dpkg-buildpackage: error: debian/rules build gave error exit status 2 > [ 111s] > [ 111s] lamb16 failed "build osmo-pcu_0.3.20170311.dsc" at Sat Mar 11 19:57:22 UTC 2017. > [ 111s] > [ 111s] ### VM INTERACTION START ### > [ 115s] [ 102.127065] reboot: Power down > [ 115s] ### VM INTERACTION END ### > [ 115s] > [ 115s] lamb16 failed "build osmo-pcu_0.3.20170311.dsc" at Sat Mar 11 19:57:26 UTC 2017. > [ 115s] > > -- > Configure notifications at https://build.opensuse.org/user/notifications > openSUSE Build Service (https://build.opensuse.org/)

1 0

RFC: jenkins pipeline
by Klaus Müller 13 Mar '17

13 Mar '17

Hi, >> So, what would be the actual benefits? >>* complete job config in git? (to be confirmed) Just to clarify, the Pipeline plugin on its own doesn't provide a complete config handling in git. This means only the code shown in image [3] lives in git, configurations within the "General" or "Build Triggers" tab will still be handled in the web-ui.*** For the sake of completeness the JobDSL plugin [2][ has to be mention. This plugin allows to put the entire job configuration to git and deploys jobs without previous manual setup in the web-ui. >>* faster because less things have to be rebuilt? (to be confirmed) Somehow I doubt that this improvement dependents on the Pipeline plugin, but I know to few details to have an opinion based on facts. :) >>* faster because easily parallelizable/easier integration with docker? (to be >> confirmed) first point: e.g. Pipeline can trigger "down-stream-projects/stages" after one specific part of a parallel-block/matrix-configurations-project is finished. second point: Pipeline brings a docker wrapper, so one don't have to pass one build script holding the entire build sequence when invoking the container. You can invoke as much scripts as you want within the docker wrapper. (no black-box god-script :) >> If dr.blobb and/or Max could clarify these points that would be great >> (while I guess they will clarify in depth only after actual trials). >> First tests could run on a privately setup Jenkins ... dr.blobb? For sure, let's use this Jenkins instance [1] for trials. Everyone is welcome to sign up and send me a mail to get the necessary permissions. I start migrating the OpenBSC build pipeline to Pipeline and keep you updated. Is this mailing list the appropriate communication channel? Is there already a osmocom ci wiki page, which I overlooked? I'd be happy to contribute! ~André *** Some "web-ui configurations" can be injected from the jenkinsfile, though. [1] https://jenkins.blobb.me/view/osmocom/ [2] https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin [2.5] https://jenkinsci.github.io/job-dsl-plugin/#method/javaposse.jobdsl.dsl.Dsl… [3] http://tinyurl.com/zbavrtp

6 9

Re: BS-11 Serial Interface
by Dieter Spaar 11 Mar '17

11 Mar '17

Hello Alexander, On Sat, 11 Mar 2017 00:42:32 +0100, "Alexander Huemer" <alexander.huemer(a)xx.vu> wrote: > > I was not able to measure any voltage on any of the DSUB-9 pins when the=20 > BTS is powered up, but believe that on either RX or TX there should be=20 > the voltage level of the serial line since RS232 is active low. > Has somebody seen this behavior? Maybe there is something wrong with the cable? This is from my notes about the BS-11 serial interface: The four E1 BNC connectors are here. 5 6 7 8 x x x x x x x x 1 2 3 4 2: LMT Tx (out) 6: LMT Rx (in) 4: +5V 8: GND There are two more 8-pin connectors below, you have to connect the cable to the top one (below the E1 BNC connectors). The same with some pictures is also here: https://osmocom.org/projects/openbsc/wiki/BS11LMT Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: libosmocore build failure cascade
by Vadim Yanitskiy 11 Mar '17

11 Mar '17

Hi Max, > On a related note - are you working on moving OsmoBTS to libosmocoding? Not a whole OsmoBTS :) GSM 05.03 transcoding routines only. Right now, I am testing dynamic TS switching on UmTRX. > Are there some missing pieces before this can be done? Almost done, now we need to switch OsmoBTS to use libosmocore's implementation and remove the old code. With best regards, Vadim Yanitskiy.

1 0

Unknown HFC multiport controller
by Alexander Huemer 11 Mar '17

11 Mar '17

Hi, I have a Siemens BS-11 and a HFC IOB1E1 PCI card. The linux kernel is not very happy with the card, I get Unknown HFC multiport controller (vendor:1397 device:30b1 subvendor:1397 subdevice:b543) Please contact the driver maintainer for support. The same error is mentioned in [1] but with different subdevice id, which I believe does not matter. I am not sure why vendor ID 1397 (PCI_VENDOR_ID_CCD) and device ID 30b1 (PCI_DEVICE_ID_CCD_HFCE1) are not valid. Consulting [2] I was under the impression that this is the expectation of the driver. [1] does not provide an answer as far as I can see. Would anybody know what the problem is here? -Alex [1] http://lists.osmocom.org/pipermail/openbsc/2009-August/001838.html [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/driver…

1 0

MNCC ABI changes
by Holger Freyther 10 Mar '17

10 Mar '17

Hi, as part of looking into early media (and at some point handover handling) I would like to use MNCC_RTP_CONNECT and supply "recvonly", "sendonly" attributes. The gsm_mncc_rtp structure does not carry this information though. struct gsm_mncc_rtp { uint32_t msg_type; uint32_t callref; uint32_t ip; uint16_t port; uint32_t payload_type; uint32_t payload_msg_type; }; The content of payload_msg_type currently holds anything between 0x300 and 0x03ff and I would like to split this field into two uint16_t. The reason is not to change the size of the structure (and maybe not dump the protocol version). It would be a backward compatible change. Is anyone open for such tricks? Otherwise I will bump protocol version and change the ABI (and try to update the various active users of this protocol). holger

2 1