OpenBSC August 2017

openbsc@lists.osmocom.org

19 participants
43 discussions

osmocom.org redmine unable to register new users?
by Neels Hofmeyr 28 Aug '17

28 Aug '17

I notice that our osmocom.org redmine no longer seems to send out registration mails. See https://osmocom.org/issues/2466 ~N

1 0

osmo-msc patch series from openbsc.git
by Neels Hofmeyr 28 Aug '17

28 Aug '17

I rebased the recent openbsc.git patches to osmo-msc.git and am submitting all of them on gerrit, to make sure each passes the tests. Since they are already accepted on openbsc.git, I'll also directly +2 and merge them. We will be re-using the same Change-Ids from openbsc.git, and I checked: if multiple commits match the same change-id, a search on gerrit will simply list all matches, so we're not losing any information. https://gerrit.osmocom.org/#/q/Ie7cdf16232181d4b8093e61f2d8a3faed9010d4f ~N

2 2

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 23 Aug '17

23 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 23 Aug '17

23 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 19 Aug '17

19 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 16 Aug '17

16 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC August 2017