OpenBSC September 2017

openbsc@lists.osmocom.org

26 participants
54 discussions

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

09 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

release process review
by Neels Hofmeyr 03 Sep '17

03 Sep '17

I'm reading through https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release and noting things as I go... > library vs. non-library projects This is not a thing and should disappear from the release process. We have many projects that build programs as well as install libraries. I see this is about the *_LIBVERSION, right? ... maybe we can say something like "adjust *_LIBVERSION (not required if the project does not install any libraries)" ? > "adhere to RERO better" RERO -- had to look it up, Eric's quote of "Release early, release often" :) And lol, the PDF link there refers to papers written basically by the "private club" of my former colleagues at the Subversion project :) Eric, Justin, Hyrum, all Subversion folks. Interesting side fact is that Subversion has never had time-based releases, despite one hackathon vote accepting that as policy. One detail though is that technically we do radical Release Early, because all of our code is on public git immediately. I'm not sure that Eric's quote refers to actual glorified "stable" releases, I understood as "make available early". Anyhow, this paragraph seems unrelated to the tagging process, could be related to the time-based package feed releases (see below). > "Proposed policy:" We already have what I'd call a loose bunch of accepted policies after OsmoDevCon 2017 and mails following it. It is first of all important to note a profound difference between two things we're aming for: providing a package feed with a global glorified state (time based), and the individual version tags in each git (feature based). With this in mind, recall the thread starting with: https://lists.osmocom.org/pipermail/openbsc/2017-April/010569.html Let me summarize: - "Global" package feeds We are planning to provide package feeds in a time-based fashion, by pinning code states and providing built packages. This is mostly a service to our user base, so that they can easily communicate and update to versions. They are to be called osmocom-cell-net / OsmocomCellNet and will have year+month based version numbers, YY.MM like 17.03 17.06 17.09 17.12 and, quote: > > I suggest that we follow a regular release schedule of: at the beginning > > of March, June, September and December. (so that we don't need to roll a > > release during/right after the festive season, i.e. not on 1st January) At this point we might aim at an OsmocomCellNet-17.12 package feed to be out on 1st of December. These feeds will not wait for features or code-freeze ahead. We will simply pin a certain point in time. If serious bugs arise we might choose to adjust, but the advice is to then just use the previous / wait three months for the next. - Individual git tree version numbers In contrast to the global package feeds, each git tree has its own local version with a git version tag. This does not follow the year+month scheme but rather "1.2.3" major.minor.patch. Compatibility is reflected in these version numbers, i.e. big incompatibilities require a major version bump, mere internal fixes can bump the patch version. (So far I understood the wiki page "Make a new release" referring to only these individual git repository versions, but we must clarify the two different concepts on that page and at least refer to a package feed wiki page.) How do the global package feeds correspond to individual major-minor-patch versions? For each of the global feeds, we should make sure that the precise git trees that are packaged correspond 1:1 to local git version tags. I.e. before we roll out a package feed, we make local version number tags to glorify the current master branch in each repository (bumping versions according to compatibility considerations) and actually use those precise version tags to mark the state that will go out in the OsmocomCellNet-YY.MM feed. So, while the time-based package feeds will be one driving force behind bumping individual version numbers, we are technically still able to mark new local version tags here and there independently from the time-based feeds. To avoid confusion, rather than talking of "release" it could help to talk of "package feed" versus "git version tag". > master branch is expected to depend on latest master branches of depended-upon projects The master branch HEADs are in constant flux, the requirement that each master works with the other latest masters is more of a daily development requirement enforced by our gerrit +V builds. For feeds and tags, we should not even mention "master branch" anywhere. Rather, the entire process *must* refer to specific version tags *everywhere*. But I'm not entirely sure how to put it. It is possible that we already have libosmo-foo 1.2.3 out, but osmo-bar also still builds fine with libosmo-foo 1.2.1. I guess all we need is that configure.ac version requirements are accurate. We will not always have to depend on the latest version number that's out, and if older ones work, ./configure should *not* require the most recent version. How to verify? I guess a version tag of osmo-X must verify - that building with the precise minimal versions requested in configure.ac works AND - that building with the currently latest tagged version of each depended-upon project also works AND - that building with each intermittent version of each dependency also works??? That's turning out rather complex ... maybe verifying with only the oldest required and the latest tagged versions is enough? > make release of depended-upon projects if necessary before making non-library project release So, are you saying, if foo needs bar which needs baz, releasing foo requires also releasing bar, in turn needing a release of baz first? ... "if necessary" :) To spell it out: this is not necessarily required; only when foo is using new API of bar that is not available in a tagged version of bar yet are we forced to make a version tag of bar and depend on it. BTW, this is implicit by "it must build with the version requested by configure.ac". The text on that wiki page before your edits did say exactly that: >> As soon as a feature is added to one Osmocom project that is needed for >> another dependent project to compile, we should tag at least a minor-revision >> bump in the depended-upon project and require it in the depend[ent] project's >> configure.ac. IMHO that's still exactly what it should say there. For the global package feed we choose to tag a new version everywhere so that we can pinpoint the current state that we want to glorify, but it is not strictly required for a local version bump to also tag depended-upon gits. > make sure that we have correct version dependencies before making non-library project release IOW: make sure configure.ac reflects the version number of depended-upon gits that are the minimum requirement to build. (scratch the "non-library") Ok great, I've reviewed the first paragraph :) Well, there was a lot of ground to cover, I hope I can do the rest less verbosely... > modify *_LIBVERSION in Makefile.am as necessary according to TODO-RELEASE file would be good to clarify what you mean, e.g. by an example. BTW, I find RANAP_LIBVERSION in osmo-iuh, ABIS_LIBVERSION and TRAU_LIBVERSION in libosmo-abis and LEGACY_MGCP_LIBVERSION in osmo-mgw; that's all. Do we need a lot more *_LIBVERSION everywhere, starting with libosmocore? Also it would be good to embed this in the list of steps under "common steps" ... i.e. have just one list of steps standing out clearly; Ideally I can start reading at the top and follow the steps one by one. > The release helper is trying to be smart about it and prevent making new > library release with non-empty TODO-RELEASE file if *_LIBVERSION is not > adjusted beforehand. Not sure I understand. I can either empty out TODO-RELEASE or change *_LIBVERSION? If I modify *_LIBVERSION, I can make a release despite TODO-RELEASE being nonempty? > Use following guidelines when choosing release type: I'd guess at major: Previous API is no longer available, ABI has changed incompatibly. minor: Additions to public API/ABI are present. patch: API/ABI unchanged, internal changes only (like bugfixes). > Deprecation policy I think we should never remove deprecated functions unless it would cause us inhumane pain to still include them. Dropping them would require a major version bump. > TODO-RELEASE file format and maintenance would be excellent to provide an actual example there > How to (re)tag a new release Is tagging and re-tagging the same? Do I need to delete a tag first? A word to clarify that would be good. Also, above it says re-sign, is that the same thing? Still unclear to me is, do I first tag a version, then do 'make release', and then I need to re-tag / re-sign again? A clear sequential list of steps and/or a complete screen dump example would be very helpful to grok it. [I remember OpenBSD CD sets having a complete listing of the default installation in the CD booklet :) ] Finally, I tried to call 'make release' but face these problems: ▶ make release /bin/bash: bumpversion: command not found ▶ apt-cache search bumpversion (no results) Though I find 'bumpversion' on packages.debian.org, I am unable to install it with 'apt-get'. https://packages.debian.org/buster/bumpversion It says "Packages / buster (testing) / devel / bumpversion" ...do I need to add "devel" to my apt sources somehow? Do we really need bumpversion? Can I instead bump the version manually? Also: ▶ make release /bin/bash: bumpversion: command not found osmo-release.mk:13: *** Please fix versioning to match http://semver.org/ spec (current is 1.0.1.115-f7251) before proceeding.. Stop. The intended version should be 1.0.2. Is that because bumpversion is not available? (Shouldn't it abort right away when bumpversion is missing?) I tried to also tag a version first so that git-version-gen produces a clean semver version: ▶ cat .version 1.0.2 but still get ▶ make release /bin/bash: bumpversion: command not found osmo-release.mk:13: *** Please fix versioning to match http://semver.org/ spec (current is 1.0.2) before proceeding.. Stop. (i.e. now it complains about "1.0.2" not being semver, which is inaccurate) Can you document these pitfalls on the wiki as well, please? ~N (P.S.: "first .. then" and "if .. then" ... it's almost always "then" with "e".)

2 1

[PATCH 1/2] pq_alsa.c: handle output buffer underrun
by Vadim Yanitskiy 02 Sep '17

02 Sep '17

On some systems the ALSA output buffer is pretty big, and if the audio samples are not being passed into the buffer quickly enough, it becomes starved for data, resulting in an error called underrun. Previously, when it happenned, GAPK used to stop processing with the following message (where X is a random number): [+] PQ: Adding ALSA output (dev='default', blk_len=320) [!] pq_execute(): abort, item returned -1 [+] Processed X frames According to the ALSA documentation, the pcm_handle changes its state when the problem happens, and should be recovered using the snd_pcm_prepare() call. This change actually does that. --- src/pq_alsa.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/pq_alsa.c b/src/pq_alsa.c index 9cee426..a3435dd 100644 --- a/src/pq_alsa.c +++ b/src/pq_alsa.c @@ -57,7 +57,15 @@ pq_cb_alsa_output(void *_state, uint8_t *out, const uint8_t *in, unsigned int in struct pq_state_alsa *state = _state; unsigned int num_samples = in_len/2; int rv; + rv = snd_pcm_writei(state->pcm_handle, in, num_samples); + if (rv == -EPIPE) { + /* Recover from buffer underrun */ + snd_pcm_prepare(state->pcm_handle); + /* Send a new sample again */ + rv = snd_pcm_writei(state->pcm_handle, in, num_samples); + } + return rv == num_samples ? 0 : -1; } -- 2.14.1

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC September 2017