OpenBSC September 2017

openbsc@lists.osmocom.org

26 participants
56 discussions

Registering problem on osmo-bts
by Sandi Suhendro 08 Sep '17

08 Sep '17

Dear guys, anyone can help me, Im using osmo-gsm-tester osmo-bts.cfg and openbsc.cfg also/ BTS is up and auth policy accept-all is set and even I add subscriber IMSI, but my phone still cannot register on the network. my setup is LimeSDR and using the latest osmo-bts and openbsc with OpenUSRP. do you think its a hardware issue? please help! Thanks -- best regards, DUO

3 4

OsmoBTS after NITB split
by Max 08 Sep '17

08 Sep '17

Hi. The OsmoBTS build depends (unfortunately) on OpenBSC because it uses gsm_data_shared.h header. ATM this file is available in osmo-bsc and osmo-msc (maybe other split repos as well). Which is the "canonical" one from OsmoBTS point of view? Also, when would be the right time to move OsmoBTS' jenkins job to use one of the split repos instead of old OpenBSC? -- 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 3

jenkins slave setup and artifact re-use
by Neels Hofmeyr 08 Sep '17

08 Sep '17

Hi Blobb, I'd like to probe your opinion on a discussion we had today about our jenkins. So far our setup was manual, and we would like to (somewhat) automate the process of providing build dependencies on slaves. One solution that was discussed longer than others would be to use docker. Each of our repositories that need a build would have their own docker file, containing the complete setup of dependencies. The idea is that anyone can easily setup an identical build on any new jenkins build slave or even at home; no complex config of the jenkins build slave is needed. The point being, if we adopt docker in such a way, it would be logical to make use of the docker cache to save unnecessary rebuilds. It is a generic solution instead our artifact store. I feel a bit bad for accepting your contributions, doing review and keeping you busy, just to then talk about docker to solve the problem instead; I appreciate your presence and would like to keep you involved. Interestingly enough, we are experimenting with the artifact store on that one build job that has already been using docker for quite some time... (It was for the separate network space, not really for artifacts.) In any case, I would like to include you in the discussion, and maybe you would also like to be involved in maturing the idea? Until now it is still wild and no-one has taken actual steps. An example to follow would be laforge's recently added https://git.osmocom.org/docker-playground/tree/ One interesting bit is that it has a method to check whether a given git branch has changed, and rebuilds the docker image only if it has: https://git.osmocom.org/docker-playground/tree/osmo-ggsn-master/Dockerfile#… ADD http://git.osmocom.org/openggsn/patch/?h=laforge/osmo-ggsn /tmp/commit This line fetches the given URL (in this case the latest patch on that branch) and considers the docker image as unchanged if that URL shows the same as last time. As soon as a new patch shows, things are rebuilt. In this sense we could have docker images cascading on top of each other, adding individual dependencies and reusing identical states auto-detected by docker. All build steps would be in the Dockerfile. For builds that aren't used by other builds (like the "final" programs, osmo-msc, osmo-sgsn, osmo-bsc,...) we don't need to store the result, so don't need to include the program's build in the Dockerfile: on a docker image with all dependencies, run the final build step by invoking 'docker run', like we currently do for the OpenBSC-gerrit job, and then just discard the changes. Remotely related: we have the osmo-gsm-tester that is running binaries produced by jenkins to do automated tests on real GSM hardware. Currently we compile and tar the binaries, copy them over, extract, set LD_LIBRARY_PATH and run: a bit tedious and problematic e.g. for mismatching debian versions. This could be simplified by docker by guaranteeing a fixed operating system around the binary, actually using hub.docker.com (or maybe one day a private docker hub) instead of copying over binary tars manually, sharing across any number of build slaves, and with the added bonus of having the resulting binaries run in a separate network space. As I said, on the one hand I appreciate our work on the artifact store, on the other hand the docker way undeniably makes for a good overall solution to simplify things in general, with artifact re-use coming "for free"... One advantage of the artifact store though is that the artifacts we manage are not entire debian installations but just a few libs and executables in a tiny tar. What is your opinion? ~N

3 9

virtphy and MT SMS
by Keith Whyte 08 Sep '17

08 Sep '17

Hi all! I just installed and configured osmo-bts-virtual and osmocom-bb with virtphy. Let me say - this is brilliant! It's so easy to do such things as trigger IMSI Attach and Detach - so much easier than entering and exiting airplane mode or power off/on. Also, MO sms is a breeze.. I have a script to inject SMS regularly, so I don't have to turn to the mobile and press buttons with each code change in my SMS handler, I just make the change and wait for the next SMS to hit it! So thanks so much to those responsible for making this happen! Now, one thing that is failing badly for me right "out-of-the-box" is MT SMS. As I am totally new to the osmocom-bb code, I guess the best would be a ticket with some pcaps, but I thought I would ask first if it is a known issue? Basically, BSC is doing this: DLSMS <0024> gsm_04_11.c:127 GSM4.11 TX [HEX of msg redacted] DLSMS <0024> gsm0411_smc.c:247 SMC(954) TC1* timeout, retrying... while on the mobile side: <0005> gsm48_mm.c:3909 (ms 1) Received 'RR_EST_IND' from RR in state MM idle (sapi 0) <0005> gsm48_mm.c:912 new state MM IDLE, normal service -> wait for network command Then this repeats: <0001> gsm48_rr.c:4775 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4777 Indicated tx_power 19 <0001> gsm48_rr.c:4799 ACCH message type 0x00 unknown. <0001> gsm48_rr.c:664 MON: f=56 lev=>=-47 snr= 0 ber= 63 LAI=262 42 0001 ID=0000 TA=0 pwr=19 TS=1/1 <0001> gsm48_rr.c:2866 MEAS REP: pwr=19 TA=0 meas-invalid=0 rxlev-full=-47 rxlev-sub=-47 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 7 <0001> gsm48_rr.c:2161 PAGING ignored, we are not camping.

2 1

catch-22 VTY error
by Neels Hofmeyr 07 Sep '17

07 Sep '17

I'd like to share a VTY config error analysis that has a tricky solution: I started osmo-bsc -c osmo-bsc.cfg with, according to openbsc/doc/examples/osmo-bsc: net [...] bts 0 [...] periodic location update 30 trx 0 [...] and get this error: There is no such command. Error occurred during reading below line: trx 0 what? 'net / bts / trx' is no command?? Solution: I'm on the vlr_3G branch (incorporating 2G via A-interface) and on this branch, I've actually moved the 'periodic location update N' command a level up, from net / bts / periodic to net / periodic (background: assuming that OsmoMSC does not have individual BTS info, we moved some settings up to network level; whether this makes sense for osmo-bsc is a different question, it's just what happens to be on the vlr_3G branch now). So there is no net / bts / periodic command. Why do I get an error for net / bts / trx instead? two reasons: 1. 'trx 0' was the line following the 'periodic' command, 2. since 'periodic' exists one level above, the vty code goes to the parent node automatically. About 2: we tend to indent our VTY config files, but in fact the indentation has no effect whatsoever, it is just eye candy (very useful eye candy). The code in question: If a command does not exist, try 'vty_go_parent()' and see if the command exists there. That's what allows us to omit 'exit' in our config files to go to the parent node explicitly: libosmocore/src/vty/command.c: int config_from_file(struct vty *vty, FILE * fp) { int ret; vector vline; while (fgets(vty->buf, VTY_BUFSIZ, fp)) { vline = cmd_make_strvec(vty->buf); /* In case of comment line */ if (vline == NULL) continue; /* Execute configuration command : this is strict match */ ret = cmd_execute_command_strict(vline, vty, NULL); /* Try again with setting node to CONFIG_NODE */ while (ret != CMD_SUCCESS && ret != CMD_WARNING && ret != CMD_ERR_NOTHING_TODO && is_config_child(vty)) { HERE -----> vty_go_parent(vty); ret = cmd_execute_command_strict(vline, vty, NULL); } cmd_free_strvec(vline); if (ret != CMD_SUCCESS && ret != CMD_WARNING && ret != CMD_ERR_NOTHING_TODO) return ret; } return CMD_SUCCESS; } In this case the 'periodic...' command does in fact now exist one level above, so the vty_go_parent() is successful and running that command works. But, the vty config parsing then sits above on the 'network' level, is no longer in 'bts 0' and hence refuses to accept the following bts-level command, in this case 'trx 0'. Confusing! So it's not a bug, it's a feature. But it's a feature we might see quite often if we move the 'periodic' command up to network level and users attempt to use their old config files. Same goes for the 'timezone' command, BTW, so we might want to rename commands, or re-consider moving commands one level up in the first place. Maybe we should leave backward compat catchers in place that print a warning. ~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 4

jenkins build slaves: Rationale for some builds in docker vs. some not?
by Harald Welte 06 Sep '17

06 Sep '17

Hi! We have some builds that happen inside a docker, and some that happen natively on the (Debian 8) build slave. Can somebody involved with this illustrate why that is the case, and what's the rationale here? Just looking at the setup, I'm unable to figure out whether there's any particular reason for this, or whether it's simply "we started without and then did some builds in docker but nobody migrated the other builds over" >From my point of view, I would have assumed that building in different containers would make sense to e.g. build on different distributions / versions, or building against older libosmo* vs. building against libosmo* from nightly package feeds vs. re-building all dependencies from master. But it appears that only a single container is built, and that container is used for some jobs (like osmo-msc-gerrit) but not for other jobs. If I missed some wiki page or mailing list posts with related information, a pointer would be helpful. Thanks in advance. 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)

4 5

Re: jenkins and osmo-ci
by André Boddenberg 05 Sep '17

05 Sep '17

Hi Neels, Patchset for openBSC's jenkins.sh build script has been uploaded [1]. But a small change [2] of osmo-build.sh is necessarily pending, because https://git.osmocom.org is down atm. Furthermore, the osmo-build.sh script should probably not depend on cgit's availability. :) After [2] has been submitted following steps are necessary to verify [1] via gerrit: - trigger "update-osmo-ci-on-slaves" - add ARTIFACT_STORE environment variable to all slaves/nodes e.g. [3] - add following arguments to docker invocations of openBSC jobs [4]: -e JOB_NAME="$JOB_NAME" -e ARTIFACT_STORE="/ARTIFACT_STORE" -v "$ARTIFACT_STORE:/ARTIFACT_STORE" Afterwards, re-triggering [1] should result in a '+1 Jenkins Builder'. I have sufficient permission to apply above stated steps, except +2'ing [2] and you may want to suggest the absolute path for ARTIFACT_STORE variable? Regards, André [1] https://gerrit.osmocom.org/#/c/3823/ [2] https://gerrit.osmocom.org/#/c/3822/ [3] https://jenkins.osmocom.org/jenkins/computer/OsmocomBuild1/configure [4] https://jenkins.osmocom.org/jenkins/view/Jenkins-Gerrit/job/OpenBSC-gerrit/

2 1

cgit.osmocom.org was down / ezjail disk quota managed by zfs
by Neels Hofmeyr 04 Sep '17

04 Sep '17

Just now I only got long waits and then "502 Bad Gateway" on git.osmocom.org ... the cgit ezjail hit its root partition limit. I had to re-figure out what I did last time, tried to find ezjail-admin options until finally I ended up back in zfs and started remembering... I increased the zfs quota for the cgit jail from 10G to 15G. Now it's working again. For the record, resizing an ezjail goes like # zfs list # zfs get quota tank/jails/cgit # zfs set quota=15G tank/jails/cgit (so next time I can find it in my mail archive, and I guess it should go in a wiki somewhere. On osmocom.org?) Last time it was the jenkins jail hitting disc limits. Then I said "We should probably set a refquota so that the live file system's quota is somewhat independent from the quota used for snapshots." I see the jenkins jail now has a 40G refquota, but the others seem not to. How does it work, set a huge quota to allow space for snapshots, and limit the fs itself by a refquota? ~N

3 8

is OAP used?
by Neels Hofmeyr 03 Sep '17

03 Sep '17

Some time back we implemented OAP to add an authentication layer to the IPA, IIRC aimed at osmo-bsc_nat <-> MAP proxy to do milenage mutual auth. Now the oap protocol code is in libosmocore, but the oap_client code is dup'ed in osmo-{bsc,sgsn}.git. I would move the oap_client to libosmocore as well. But all the while I'm not really certain that it is indeed being used. osmo-sgsn has vty config for it, but I'm certain osmo-hlr doesn't bother to implement the OAP server part (there's code but in #if 0). osmo-bsc_nat remains, and possibly a GSUP counter part to the osmo-sgsn that I'm not using (presumably the MAP proxy)? Is anyone using OAP and the oap_client and is it worth the effort to keep it? Can we / should we just drop OAP instead? Thanks, ~N

1 1

[PATCH] Fix BENCHMARK_STOP call for AMR and FR
by Vadim Yanitskiy 03 Sep '17

03 Sep '17

--- src/codec_amr.c | 4 ++-- src/codec_fr.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/codec_amr.c b/src/codec_amr.c index 4aae733..ca614ed 100644 --- a/src/codec_amr.c +++ b/src/codec_amr.c @@ -78,7 +78,7 @@ codec_amr_encode(void *state, uint8_t *cod, const uint8_t *pcm, unsigned int pcm (unsigned char*) cod, 1 ); - BENCHMARK_STOP(CODEC_EFR, 1); + BENCHMARK_STOP(CODEC_AMR, 1); return rv; } @@ -95,7 +95,7 @@ codec_amr_decode(void *state, uint8_t *pcm, const uint8_t *cod, unsigned int cod (short *) pcm, 0 ); - BENCHMARK_STOP(CODEC_EFR, 0); + BENCHMARK_STOP(CODEC_AMR, 0); return PCM_CANON_LEN; } diff --git a/src/codec_fr.c b/src/codec_fr.c index 2ce44b4..917f34b 100644 --- a/src/codec_fr.c +++ b/src/codec_fr.c @@ -74,7 +74,7 @@ codec_fr_decode(void *state, uint8_t *pcm, const uint8_t *cod, unsigned int cod_ memcpy(cod_b, cod, FR_CANON_LEN); BENCHMARK_START; rc = gsm_decode(gh, (gsm_byte*)cod_b, (gsm_signal*)pcm); - BENCHMARK_STOP(CODEC_FR, 1); + BENCHMARK_STOP(CODEC_FR, 0); if (rc < 0) return rc; return PCM_CANON_LEN; -- 2.14.1

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC September 2017