OpenBSC May 2017

openbsc@lists.osmocom.org

26 participants
60 discussions

static builds in jenkins
by Max 30 May '17

30 May '17

Hi. Most (if not all) of Osmocom libraries can be built for static linking. With the addition of https://gerrit.osmocom.org/#/c/2748/ we can leverage this to also build static OpenBSC which comes in handy while testing from time to time. Would be nice to add this option to jenkins as well (for OpenBSC as well as all the libraries). What do you think? -- 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

4 5

Re: OsmocomBB compile testing / Re: libosmocore embedded build
by Craig Comstock 30 May '17

30 May '17

I was thinking about how to setup an automated real device test for the repo and/or PRs especially. I have devices and cables, just was thinking about how to automate the re-loading of firmware (via an interface to the power button I suppose). Any work ongoing on this front? I'd be happy to contribute as I have a server I'm going to use for nano3g, calypsobts, development. -Craig -------------------------------------------- On Thu, 5/18/17, Harald Welte <laforge(a)gnumonks.org> wrote: Subject: OsmocomBB compile testing / Re: libosmocore embedded build To: "André Boddenberg" <dr.blobb(a)gmail.com> Cc: baseband-devel(a)lists.osmocom.org, "OpenBSC" <openbsc(a)lists.osmocom.org>, "Vadim Yanitskiy" <axilirator(a)gmail.com> Date: Thursday, May 18, 2017, 1:24 PM Hi Andre and others. We currently have a series of patches from Vadim pending in gerrit for OsmocomBB. They cannot move ahead, as we have no compile testing / jenkins job which would give this a +1. To resolve this, we should also start to have a jenkins compile testing job for OsmocomBB. The "host" (PC) part of the code is built against regular libosmocore, just like e.g. openbsc or osmo-bts. That should be possible even so far, and it might make sense to start with that. Basically you need to: * git clone osmocom-bb * cd src/host/layer23 * regular 'autoreconf -fi && ./configure && make' compile-testing the 'embedded' (firmware) part is not possible easily in the current master. However, as a second step, and after the libosmocore embedded build has run (and it is installed to /usr/local/arm-none-eabi), and if you use the laforge/remove-libosmocore branch in OsmocomBB, you should also be able to compile-test the firmware using * git clone osmocom-bb * cd src/target/firmware && make There currently is no "make check" tests for either the host utilities or the firmware, and of course we have no clue if the resulting binaries will do anything useful on an actual pone [yet!], but I still think the two steps above would be very useful to move ahead, and to unify the patch submission/review/verification/approval/merge process in gerrit with what we have established for the network-side projects like OsmoBTS & co. 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)

2 2

m3ua and sua testing as part of jenkins?
by Harald Welte 29 May '17

29 May '17

Dear all, for some time, I've been wanting to have an easy way to run m3ua-testtool and sua-testtool as part of our regular regression testing setup. After some very disappointing trials using docker (see my blog), I managed to make this work using the 'unshare' program (part of util-linux). The key regquirement basically is: * create a network namespace * configure some netdevice / ip adresses in it * run the software under test (osmo-stp in this case) * run the test suite * tear down everything Initially I tried to do this using 'ip netns', but the problem is that you normally require root permissions to configure the netdevice inside the new namespace. And being root is of course difficult if you think of a jenkins build slave. However, 'unshare' offers the ability to map your real UID to root inside the namespace. At that point, everything can be done as non-root. The resulting scripts are in libosmo-sccp/contrib/test: "run-in-ns.sh" is a simple wrapper around unshare, so you have to call something like ./run-in-ns.sh ./test-m3ua.sh In order to use the m3ua-testtool, you will need to * install guile * clone + build + install https://github.com/nplab/guile-sctp * clone + build m3ua-testtool and sua-testtool from git.osmocom.org, no installation of this require. I would appreciate feedback from others trying to reproduce the above setup on their machine[s]. All tests should be GREEN/PASS. If anyone knowns how to integrate this with jenkins for libosmo-sccp,I think it would be great to have this as part of our testing of gerrit patches. I'm not so sure if it makes sense to try to integrate this with "make check", as it is not a unit test (and it would only work on Linux). I'm planning to use the saee "run-in-ns.sh" approach for my SCCP level tests implemented in TTCN-3/Titan. One further idea is if it make sense to report the test reuslts in a more friendly way. Right now it's deailed osmo-stp logs interspersed with output from the tester. Mayb there's some more information we can feed back into jenkins? Again, I have very little understanding of jenkins. 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)

2 7

gapk jenkins integration
by Harald Welte 29 May '17

29 May '17

Dear all, gapk (the GSM Audio Pocket Knife) now has tests that can be executed in order to determine if encoding and decoding from/to most supported formats still work "most" as the file source can only read codecs with fixed block size, so AMR cannot be tested yet. It would be great if somebody[tm] would jump in to add this to jenkins, so new commits can be tested against this. Thanks in advance! The test is not integrated with autotest, I wasn't sure if it makes sense. Probably yes, to unify with other projects? In either case, after a successful 'make', you should be able to do a (cd test && ./test_all_formats.sh) and get some meaningful output as well as a status code (1 = error, 0 = success). Patches for autotest integration or any other step towards CI integration is much appreciated. I'm planning to disable direct git commit and move patch submissions to gerrit soon, too (to get the benefit of pre-merge patch verification). I'll also be working on some usage examples on gapk in the redmine wiki and/or included with the tool. By now you can use it as a RTP sink to transcode an RTP stream and play it back on your sound card via ALSA, which is very useful, particularly in combination with a patch that will enable you to issue a MDCX from the BSC VTY, requesting the BTS to redirect the RTP stream e.g. to that gapk RTP sink. 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

Illegal instruction error
by Max 28 May '17

28 May '17

Hi. It seems like some of the recent changes to libosmocore cased following build failures: [ 216s] +/usr/src/packages/BUILD/tests/testsuite.dir/at-groups/9/test-source: line 25: 28875 Illegal instruction $abs_top_builddir/tests/conv/conv_gsm0503_test See https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/l… Could you please have a look as to what's causing it? I'm also puzzled by the build failing on 16.10 only. Versions 16.04 and 17.04 seems to be fine. -- 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 3

redmine search for issues problem
by Neels Hofmeyr 28 May '17

28 May '17

Just noticed, in redmine, it's best to search without any projects selected, even if they are the parent of some others you intend to search in: - go to osmocom.org - enter 'AoverIP' in the search field (do not select a particular project). - find 5 issues, they are from projects OsmoMSC and OsmoBSC. versus: - select 'Cellular Infrastructure', next to the search field at 'Jump to a Project' - enter 'AoverIP' in the search field. - Find no issues at all. Why? OsmoMSC and OsmoBSC are both subprojects of Cellular Infrastructure. ... good to know. ~N

1 0

Half Rate Codec (GSM-HR-08)
by Ron 24 May '17

24 May '17

Hi All, We are having “INCOMPATIBLE_DESTINATION” error in Freeswitch using the half rate configuration of each timeslots in NITB. Our setup have 1 OSMO-NITB (with OSMO-BTS-TRX, OSMO-TRX, and OSMO-SIP-CONNECTOR) and 2 Freeswitch. One of the Freeswitch is local in the server while the other Freeswitch is at the cloud. Using the Full Rate Configuration of each timeslots, we do not encounter the “INCOMPATIBLE_DESTINATION” error and we successfully connected 2 phone calls. Upon using the Half Rate Configuration, "INCOMPATIBLE_DESTINATION” error occurs. We played around the codecs of Freeswitch but unfortunately, we were not able to complete the call. It always disconnects the call immediately after the MT answers. Does anyone tried this kind of setup before? What equivalent codec does the “default-codec tch/h hr” or GSM-HR-08 as seen in Freeswitch? OS: Ubuntu 16.10 OSMO Elements: OSMO-TRX OSMO-BTS-TRX OSMO-NITB OSMO-SIP-CONNECTOR SDR: Ettus B210 Softswitch: Freeswitch (Version 1.6) Attached are the config files used for OSMO Elements. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

2 2

libosmocore embedded build
by Harald Welte 24 May '17

24 May '17

Dear all, when we originally moved a lot of generic code from OpenBSC to libosmo{core,gsm} to re-use it from OsmocomBB, we created an 'embedded' build of libosmocore, which can use [most of] the library code also in deeply embedded, OS-less 'bare metal' microcontroller environments. The ability to build libosmocore this way has been broken for many years, but I've fixed that in recent libosmocore master. Below command works for me [tm]: ./configure --prefix=/usr/local/arm-none-eabi \ --host=arm-none-eabi \ --enable-embedded \ --disable-shared \ CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs" What we'd need now is: 1) make sure embedded builds continue to work by building libosmocore for embedded as part of the jenkins setup (using gcc-arm-none-eabi debian package). Any volunteers? 2) start to use this embedded build from simtrace2 firmware, osmocom-bb and the upcoming fimrware for the RFDN[1]. So far, * osmocom-bb uses an old clone of libosmocore, * simtrace2 is using some copy+pasted fork of some libosmocore files * rfdn is using some copy+pasted fork of some libosmocore files The above is no longer required. 3) consider if we can shrink the resource requirements of some libosmocore parts. One issue coming up are the static buffers in osmo_hexdump[] or the like. If your total processor RAM is 8k or 16k, then spending 4k on the buffer for hex-dumping is indeed a bit excessive. Any help is appreciated, particularly on the jenkins side. Regards, Harald [1] (1:8 splitter-combiner with adjustible step attenuators, part of the osmo-gsm-tester setup we're building at sysmocom). Code will be released as soon as the hardware is validated. -- - 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 10

Re: libosmocore embedded build
by Craig Comstock 18 May '17

18 May '17

> Can someone else may have a > quick look at log [2] to point me in the > right direction? Afaics build dependencies are > available but the > compilation itself > fails. > [2] https://jenkins.osmocom.org/jenkins/job/TEST_libosmocore_arm_none_eabi/arch… Looks like the tests are failing. My build seems to work but when I run "make check-am" in tests I get a different error related to talloc. This is on a Debian 8 stable box using arm-none-eabi and newlib from debian packages. Maybe the make of timer_test fails and doesn't log somehow? I"m not sure. craig@z500:~/libosmocore/tests$ vi timer/timer_test. timer_test.c timer_test.ok craig@z500:~/libosmocore/tests$ vi timer/timer_test.c craig@z500:~/libosmocore/tests$ make check-am make timer/timer_test sms/sms_test ussd/ussd_test smscb/smscb_test bits/bitrev_test a5/a5_test conv/conv_test auth/milenage_test lapd/lapd_test gsm0808/gsm0808_test gsm0408/gsm0408_test gb/bssgp_fc_test gb/gprs_bssgp_test gb/gprs_ns_test gprs/gprs_test kasumi/kasumi_test gea/gea_test logging/logging_test fr/fr_test codec/codec_test loggingrb/loggingrb_test strrb/strrb_test vty/vty_test comp128/comp128_test utils/utils_test smscb/gsm0341_test stats/stats_test ctrl/ctrl_test bitvec/bitvec_test msgb/msgb_test bits/bitcomp_test tlv/tlv_test gsup/gsup_test oap/oap_test fsm/fsm_test write_queue/wqueue_test socket/socket_test coding/coding_test conv/conv_gsm0503_test abis/abis_test endian/endian_test sercomm/sercomm_test make[1]: Entering directory '/home/craig/libosmocore/tests' CC timer/timer_test.o In file included from timer/timer_test.c:31:0: ../include/osmocom/core/talloc.h:4:20: fatal error: talloc.h: No such file or directory #include <talloc.h> ^ compilation terminated. Makefile:1336: recipe for target 'timer/timer_test.o' failed make[1]: *** [timer/timer_test.o] Error 1 make[1]: Leaving directory '/home/craig/libosmocore/tests' Makefile:1529: recipe for target 'check-am' failed make: *** [check-am] Error 2

1 0

dependency artifacts for faster builds/gerrit-verifications
by André Boddenberg 18 May '17

18 May '17

Hi all, here's a (late) recap on the "dependency-artifacts" topic discussed with Holger and Neels at OsmoDevCon. The "mv $artifact"-issue, which occurs when run within a docker container has been resolved. Now artifacts are created inside a temporary directory within the ARTIFACT_STORE and not inside the Docker container, so the "mv" command won't take as long as a "cp" anymore. Moreover, artifacts are now stored per jenkins job and not per git project. A JOB_NAME-directory inside the ARTIFACT_STORE is created for each jenkins job to distinguish between them. This means artifacts aren't shared across jobs which build the same git project. This might change in the future, but is safe for now as some jenkins jobs might need dependencies built with different configurations. Note: the necessary disk space for openBSC artifacts of one matrix-configuration job is ~400 MB (~50 MB per axis). Furthermore, each jenkins job takes care about garbage collection on its own by simply deleting the entire content of its JOB_NAME-directory inside the ARTIFACT_STORE. The two scripts osmo-{build,artifacts}.sh have been tested [1][2], shellcheck'ed and pushed to gerrit [3]. The following actions are pending to enable the use of artifacts inside contrib/jenkins.sh within each git repository, but can not be applied by me: - setting ARTIFACT_STORE environment variable for each jenkins slave - copying osmo-artifact.sh and osmo-build.sh to ~/bin of each slave user - adding a new docker volume for the ARTIFACT_STORE to the image But, let's review first. =) Cheers, André [1] https://jenkins.blobb.me/job/openBSC_multi-configuration_withArtifacts_test… [2] https://jenkins.blobb.me/job/openBSC_multi-configuration_withArtifacts_test… [3] https://gerrit.osmocom.org/#/c/2465/

3 7

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC May 2017