OpenBSC August 2017

openbsc@lists.osmocom.org

19 participants
41 discussions

Jenkins build slave setup / messy
by Harald Welte 25 Aug '17

25 Aug '17

Dear all, I had to spend a large portion of my spare time last night in order to add a new jenkins build slave in a way that it works. What should have been very simple by following the wiki at https://osmocom.org/projects/osmocom-servers/wiki/Jenkins_Node_Setup turned out into a long process of failures that still continue, see http://jenkins.osmocom.org/jenkins/job/osmo-bts-gerrit/1325/ I'm really not happy about the lack of discipline in keeping the documentation in sync - or even bothering to state in the wiki "FIXME, some stuff needs to be done which is not documented". Having very incomplete documentation that suggests something is a very easy and straight-forward task is possibly worse than having no documentation, at which point the reader/user is clear about this being a time-consuming procedure that involved manual recreation of a manual setup. We do now have "build-2.osmocom.org", which is a Ryzen 1700X eight-core CPU with 64GB RAM. It natively runs Debian 9 (stretch) and has a Debian8 build slave inside a lxc container. I've updated the wiki page, but I don't think "copy over the ~/docker directory whose contents is not under revision control and then run ./update.sh" is all that good an idea either. Adding more build slaves to a jenkins setup should be the most natural and normal thing to do. After all, the entire system is designed to scale out by adding more build slaves. I think the right process here would be to have a script that generates the build slave[s]. My preference would be to have a lxc template for it, so any new build host simply needs to lxc-create from that template. Is anyone willing to contribute in that area? Regards, Harald -- - 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)

1 0

proper way to change network time/timezone
by Mille Fiore 25 Aug '17

25 Aug '17

Hello openbsc community! We are encountering the ff issue: When using basic phones, we have observed that the timestamps on the SMS are in UTC, even if we changed the linux system timezone to a different one. Also, if the basic phone will do an auto-update of date and time from the network, it will use the time in UTC. Do you have suggestions on how to change the network timezone configuration for the osmo-nitb? There is a timezone command mentioned in the osmo-nitb vty reference manual (timezone <-19-19> (0|15|30|45), ex. timezone 8 0 ). If we put that config under the BTS level (in osmo-nitb.cfg), osmo-nitb will complain that there is a config error. If we put that under the network level, osmo-nitb does not complain, but it doesn't seem to work as expected. Let me know if addtl info is needed. Thank you in advance!

6 9

optional vty items are stricter than expected
by Neels Hofmeyr 22 Aug '17

22 Aug '17

Trying to get the newest 2G+3G developments thru the test suites (including the vty ones), I face a problem with this VTY definition from libosmo-sccp: routing-key RCONTEXT DPC [si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)] [ssn SSN] It turns out the square braces indicating optional parameters cannot contain spaces. To test, I created foo [a] [b] which works as OsmoMSC(config-msc)# foo ? [a] a OsmoMSC(config-msc)# foo b % Unknown command. OsmoMSC(config-msc)# foo a ok OsmoMSC(config-msc)# foo a ? [b] b OsmoMSC(config-msc)# foo a b ok So far so good, but with: foo [a AA] [b] I get OsmoMSC(config-msc)# foo ? [a a OsmoMSC(config-msc)# foo a % There is no matched command. OsmoMSC(config-msc)# foo a val % Unknown command. The way this would work is foo [a] [AA] [b] and means that I can issue either 'foo', 'foo a', 'foo a val' or 'foo a val b'. Not that helpful really. With above command routing-key RCONTEXT DPC [si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)] [ssn SSN] it seems to me it is intended as optionally providing none, si or both si and ssn? I guess we need separate command definitions: routing-key RCONTEXT DPC routing-key RCONTEXT DPC si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup) routing-key RCONTEXT DPC si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup) ssn SSN Does that make sense? Until we fix it, the vty tests will not be able to match up the vty doc parameters and the python tests will fail. I grepped for all square brace vty definitions we have; the only ones attempting to include multiple args in square braces are in osmo_ss7_vty.c: ./libosmo-sccp/src/osmo_ss7_vty.c-265- "update route POINT_CODE MASK linkset LS_NAME [priority PRIO] [qos-class (CLASS|default)]", ./libosmo-sccp/src/osmo_ss7_vty.c-781- "routing-key RCONTEXT DPC [si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)] [ssn SSN]}", They aren't usable. (the 'update route...' is part of the _sg vty command set and thus not caught by osmo-msc or -bsc vty tests; osmo-stp has no vty tests so far, AFAICT) These appear to be all square brace vty definitions, most enclose only a single element and are fine: ▶ grep -n '\<DEFUN\>(' -A1 $(find . -name "*.c") | grep '[[]' ./osmo-sgsn/src/gprs/sgsn_vty.c-534- "show mm-context tlli HEX [pdp]", ./osmo-sgsn/src/gprs/sgsn_vty.c-553- "show mm-context imsi IMSI [pdp]", ./osmo-sgsn/src/gprs/sgsn_vty.c-570- "show mm-context all [pdp]", ./osmo-sgsn/src/gprs/gb_proxy_vty.c:461:DEFUN(show_gbproxy, show_gbproxy_cmd, "show gbproxy [stats]", ./osmo-sgsn/src/gprs/gb_proxy_vty.c-552- "delete-gbproxy-peer <0-65534> (only-bvc|only-nsvc|all) [dry-run]", ./osmo-bsc/src/osmo-bsc/osmo_bsc_vty.c-63- "msc [<0-1000>]", "Configure MSC details\n" "MSC connection to configure\n") ./osmo-bsc/src/libbsc/bsc_vty.c:319:DEFUN(show_bts, show_bts_cmd, "show bts [<0-255>]", ./osmo-bsc/src/libbsc/bsc_vty.c:1629:DEFUN(cfg_bts_dtxu, cfg_bts_dtxu_cmd, "dtx uplink [force]", ./osmo-bsc/src/libbsc/bsc_vty.c-3947- "bts <0-255> trx <0-255> timeslot <0-7> sub-slot <0-7> (activate|deactivate) (hr|fr|efr|amr) [<0-7>]", ./osmo-mgw/src/libosmo-legacy-mgcp/mgcp_vty.c-229- "show mgcp [stats]", ./libosmo-sccp/src/osmo_ss7_vty.c-110- "point-code format <1-24> [<1-23>] [<1-22>]", ./libosmo-sccp/src/osmo_ss7_vty.c-265- "update route POINT_CODE MASK linkset LS_NAME [priority PRIO] [qos-class (CLASS|default)]", ./libosmo-sccp/src/osmo_ss7_vty.c-781- "routing-key RCONTEXT DPC [si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)] [ssn SSN]}", ./libosmo-sccp/examples/sccp_test_vty.c-39- "connect-req <0-16777216> [DATA]", ./libosmo-sccp/examples/sccp_test_vty.c-53- "connect-resp <0-16777216> [DATA]", ./libosmocore/src/gb/gprs_ns_vty.c:216:DEFUN(show_nse, show_nse_cmd, "show ns (nsei|nsvc) <0-65535> [stats]", ./libosmocore/src/gb/gprs_bssgp_vty.c:153:DEFUN(show_bvc, show_bvc_cmd, "show bssgp nsei <0-65535> [stats]", ./libosmocore/src/vty/command.c-2965- "no service terminal-length [<0-512>]", ./libosmocore/src/vty/logging_vty.c-520- "log gsmtap [HOSTNAME]", ~N

1 1

osmo-dev.git
by Neels Hofmeyr 22 Aug '17

22 Aug '17

I just added a new repository: osmo-dev.git. For a long time I have been using hacked-up tools to help me in daily Osmocom development. A recent addition was a generator for a top-level makefile that allows one-line do-what-I-mean rebuild. That's the point where I thought it made sense to share, in case anyone else is interested in this kind of convenience. The name is taken from osmo-ci. osmo-ci is for continuous integation on our jenkins, osmo-dev is for development at home. I considered adding to osmo-ci, but the aims are actually different from osmo-ci. There are two README files, one explaining how the top-level makefile works, one in src/ explains my little git robots that are also included. The future will bring more *.deps and *.opts configs... osmo-dev is on gerrit, feel free to contribute / test / fix! If you don't agree with the naming and separate repos decision, I'd be fine to change that... ~N

1 0

Jenkins now executing M3UA, SUA and GGSN testuite
by Harald Welte 21 Aug '17

21 Aug '17

Hi all, Yesterday and today I've been working to get the test suites for M3UA, SUA and GGSN(GTP) integrated into jenkins.osmocom.org. Some more background can be found at http://laforge.gnumonks.org/blog/20170820-osmocom-testsuites/ with links to the respective jenkins jobs and git repositories of test cases and Dockerfiles + Makefiles. It's important to note that those tests are neither a competition nor a replacement for both the unit tests as well as osmo-gsm-tester. I'm not quite sure how to call them, maybe "connected tests" or the like, as they interact with our running network elements over the various protocols/interfaces. The parts that I'm not entirely sure about yet is: 1) does it really make sense to build docker images for both tester and IUT (osmo-stp in cases of M3UA/SUA tests, openggsn in case of ggsn tests)? Running both in docker containers attached to the same (internal, non-routed/public) network allows the processes to talk to each other without interfering the build host networking in any way, so it seemed like a convenient choice. Whether or not it makes sense to update both the tester and IUT container in a single jenkins job - I'm not sure. Any ideas? 2) trigger. So far I went for the nightly trigger at ~ 4am GMT. This is sufficient for now, but it could of course be triggered by polling git of both the tester and the IUT. 3) version information. I would like to get proper version information into jenkins, so we don't just know "nightly test on day X" but see on the jenkins Web UI which particular git version of IUT (and tester) was tested. Any help appreciated! 4) archiving logs. It would be great to keep the logs of not only the last test execution around. Sure, jenkins has stdout (of the tester) and junit-xml (of the tester). But things like the log file generated by the IUT is currently only present for the last test execution. Any help appreciated! I'm currently wokring on docker images for osmo-sgsn, osmo-nitb, osmo-bts-virt and virtphy, so we can extend above-mentioned setup to cover also the 'sysinfo + nitb vty' as well as the lapdm and pcu tests that I wrote in TTCN-3. After that, I plan to direct my attention more to the development of more test casese in those respective test suites, rather than optimizing the Jenkins integration. Any help both with more test cases as well as jenkins would be much appreciated. I think the hard part has been creating the entire toolchain and access to the various interfaces (Gp, Gb, Um, VTY, ...) and now it should be rather easy to write more tests. Regards, Harald -- - 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 3

OBS nightly for EoL releases
by Max 18 Aug '17

18 Aug '17

Hi. We're building nightly .deb over at https://build.opensuse.org/project/monitor/network:osmocom:nightly for several distro flavors including Ubuntu 16.10 which is already reached End of Life stage. Shall we just drop such EoL distros from nightly builds? -- 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

huge patches
by Neels Hofmeyr 17 Aug '17

17 Aug '17

In the current osmo-msc.git split-up effort that will render openbsc.git to be legacy, there are a couple of very large commits on gerrit. In normal circumstances, my comment to these would be: "split this up!" The way they came to be was: for a long time we were developing features on branches, with numerous separate small-sized commits. There were these problems with that: Many commits partly or fully reverted earlier commits. It doesn't make sense to look at small and incomplete steps in wrong directions. Rebasing this work onto recent developments became ludicrously cumbersome: solved merge conflicts were re-appearing with near every single following small commit, multiplying the effort for every little conflict resolution. It was necessary to pull these commits together to fewer steps for conflict resolution, but some refactorings were done in-between other back-and-forth changes; combining patches by topics would also have been prohibitive effort. The first step was thus to plain squash *all* into *one*. That is the current state of the libvlr changes (already merged), mscsplit changes (being merged now), IuCS (coming up) and AoIP+sigtran (coming up). If it serves review, I am ready and willing to split these up into smaller bits, but if we can avoid spending time on that by reviewing the commits as whole, we can reduce time spent on cosmetics. The special nature of these patches is that they do pretty much completely overhaul the internal wiring and data structures: it makes sense to look at it as a whole and it's hard to pull out separate changes that are orthogonal. So though this should not be the default style of our commits, this is a special situation. Do request a split up if you see a need. Otherwise we will merge them in these large code bombs as a basis for further dev. Thanks! ~N

2 1

GSM Silent call
by samir 15 Aug '17

15 Aug '17

Hi, I have read that silent-calls in GSM can be used to make a call to a target MS and listen to it without having the target knowing it. Is this theoretically possible ? If yes, can it be done in OpenBSC ?

2 1

Re: libosmocore and SSE
by Vadim Yanitskiy 15 Aug '17

15 Aug '17

Hi Neels and Harald, Is the problem related to an issue, reported by Max? https://osmocom.org/issues/2386 As I already commented, there is one possible reason: Currently, the conv_acc_sse.c is being compiled with both -msse3 -msse4.1 CFLAGS. Some compilers (or different versions) may use the msse4.1 instruction set to optimize the whole byte code, even in the places where they are not actually used. So, one possible solution is to separate the conv_acc_sse.c to conv_acc_sse_3.c and conv_acc_sse_41.c, and then compile them with -msse3 -msse4.1 flags respectively. If I had some basic compile / check access to the build host, I could check whether my assumption is correct. With best regards, Vadim Yanitskiy.

3 2

Re: Build failure of network:osmocom:nightly/openbsc in Debian_9.0/x86_64
by Neels Hofmeyr 14 Aug '17

14 Aug '17

We've seen the same in lynxis' debian builds of the split gits, and now it makes sense: The recent openggsn changes to debian rules somehow cause an oddity so that our configure check for libgtp now fails, causing all GPRS related binaries to not be built. Haven't investigated what exactly it is, but my expectation is that openggsn causes osmo-sgsn etc to fail: My guess is https://git.osmocom.org/openggsn/commit/?id=23eea1d132120198745dcca32728906… "Use osmocom-style git-version-gen / .version magic" (tagged 0.94) We try to find it by: PKG_CHECK_MODULES(LIBGTP, libgtp >= 0.92, , found_libgtp=no) log: [ 60s] [110/216] installing libgtp1-0.93.20170812 [...] [ 61s] [116/216] installing libgtp-dev-0.93.20170812 [...] [ 138s] checking for LIBGTP... no https://build.opensuse.org/public/build/network:osmocom:nightly/Debian_9.0/… ~N On Fri, Aug 11, 2017 at 08:04:10PM +0000, OBS Notification wrote: > Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o… > > Package network:osmocom:nightly/openbsc failed to build in Debian_9.0/x86_64 > > Check out the package for editing: > osc checkout network:osmocom:nightly openbsc > > Last lines of build log: > [ 176s] make[4]: Leaving directory '/usr/src/packages/BUILD/openbsc/tests' > [ 176s] make[3]: Leaving directory '/usr/src/packages/BUILD/openbsc/tests' > [ 176s] make[3]: Entering directory '/usr/src/packages/BUILD/openbsc' > [ 176s] make[4]: Entering directory '/usr/src/packages/BUILD/openbsc' > [ 176s] make[4]: Nothing to be done for 'install-exec-am'. > [ 176s] /bin/mkdir -p '/usr/src/packages/BUILD/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig' > [ 176s] /usr/bin/install -c -m 644 openbsc.pc '/usr/src/packages/BUILD/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig' > [ 176s] make[4]: Leaving directory '/usr/src/packages/BUILD/openbsc' > [ 176s] make[3]: Leaving directory '/usr/src/packages/BUILD/openbsc' > [ 176s] make[2]: Leaving directory '/usr/src/packages/BUILD/openbsc' > [ 176s] make[1]: Leaving directory '/usr/src/packages/BUILD/openbsc' > [ 176s] dh_install -O--sourcedirectory=openbsc > [ 176s] dh_install: Cannot find (any matches for) "/usr/bin/osmo-sgsn" (tried in "." and "debian/tmp") > [ 176s] dh_install: osmocom-sgsn missing files: /usr/bin/osmo-sgsn > [ 176s] dh_install: Cannot find (any matches for) "/usr/bin/osmo-gtphub" (tried in "." and "debian/tmp") > [ 176s] dh_install: osmo-gtphub missing files: /usr/bin/osmo-gtphub > [ 176s] dh_install: missing files, aborting > [ 176s] debian/rules:13: recipe for target 'binary' failed > [ 176s] make: *** [binary] Error 2 > [ 176s] dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 > [ 176s] > [ 176s] lamb17 failed "build openbsc_0.15.1.20170811.dsc" at Fri Aug 11 20:03:59 UTC 2017. > [ 176s] > [ 176s] ### VM INTERACTION START ### > [ 180s] [ 168.503704] reboot: Power down > [ 180s] ### VM INTERACTION END ### > [ 180s] > [ 180s] lamb17 failed "build openbsc_0.15.1.20170811.dsc" at Fri Aug 11 20:04:03 UTC 2017. > [ 180s] > > -- > Configure notifications at https://build.opensuse.org/user/notifications > openSUSE Build Service (https://build.opensuse.org/) -- - 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 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC August 2017