OpenBSC March 2017

openbsc@lists.osmocom.org

22 participants
51 discussions

test failures in current OpenBSC
by Max 20 Mar '17

20 Mar '17

Hi. A little heads-up - the current master of OpenBSC is failing at 'make check' stage - see http://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/2019/IU=--disable-iu,… for example. Until this is fixed, any patches for OpenBSC won't be accepted by jenkins. If you hit this - please retrigger corresponding failed build in jenkins once it's fixed. -- 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

nightly packages failures
by Neels Hofmeyr 20 Mar '17

20 Mar '17

openggsn failed because README was renamed to README.md without adjusting the debian installation rules (possibly the same change occured in other repositories, Harald?) the osmo-auc-gen_test.sh still fails on 32bit systems, to be fixed by https://gerrit.osmocom.org/2089 (please review) ~N

2 1

git.osmocom.org cgit improvements
by Harald Welte 20 Mar '17

20 Mar '17

Hi all, today I've deployed some cgit improvements on https://git.osmocom.org/, in the hope that it makes this tool even more useful: 1) syntax highlighting of source code (requested by Hoernchen) The source code is now highlighted by pygments. I don't really understand why somebody would want to look at source code a lot in a browser, but well, it was as easy as to enable the existing pygments based filter plugin. 2) rendering of "about" page from README.md As you might have noticed, I've introduced a README.md in a number of repositoires, and cgit is now rendering an about page for every repository, e.g. at http://git.osmocom.org/libosmo-abis/about/ 3) gerrit change-ID hyperlink generation All gerrit Change-IDs in commit messages are now automatically converted to hyperlinks to the respective gerrit change, see e.g. the below example: http://git.osmocom.org/openbsc/commit/?id=6dd0fc685b7149f67a5fe17a5bce55c44… Please note that this works for the "Change-Id" line of the actual change, but also for change-ids in the free text (e.g. "this depends on change-id ... in libosmocore") 4) Osmocom ticket/issue hyperlink generation Any Line that matches the "^((Relate|Close|Fixe)[ds]):" prefix is scanned for occurrences of "OS#(\d+)" which are then amended with hyperlinks to the respective issue on osmocom.org Please note the OS# prefix is mandatory, so things like "OS#1614, 1615" will not work, as can be seen at http://git.osmocom.org/osmo-pcu/commit/?id=0a8fae8d141c2cfa4387ffe9b35402d5… Please format your commit messages accordingly. 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

coverity scan for vlr_2G and vlr_3G
by Neels Hofmeyr 18 Mar '17

18 Mar '17

It seems that we won't be merging vlr_2G or vlr_3G into openbsc.git's master, at least not soon. Instead we're likely to move to a new git repository altogether to mark the changed setup. We could switch 'Osmocom' over to vlr_3G and assume that it includes the others, but that's not accurate at all. The VLR stuff cuts away half the code from openbsc.git's master and 3G the other half. well, almost :) So I thought we could repurpose two of the unused coverity scan projects we have for the vlr_2G and vlr_3G branches. Or maybe one for vlr_3G would be enough. It seems we can't change the name of a coverity project. Maybe we can just use the OpenBSC one for vlr_3G without changing the name? We could possibly also include a separate build within the tar sent to the Osmocom job, I can also check that out. Or I can try and register a brand new one. Any preferences? ~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

3 4

OsmoTRX runtime CPU optimization detection
by Harald Welte 16 Mar '17

16 Mar '17

FYI, Philipp has been working on some patches to do the OsmoTRX cpu instruction set extension detection at runtime rather than compile-time. See "Bug #1869: osmo-trx binary cannot be moved to similar CPU" https://osmocom.org/issues/1869#change-3394 As not everyone is following each redmine ticket or gerrit patch: I would like the OsmoTRX folks (Tom, Alexander, ...) to have a look at this. For convenience, the latest update to the ticket and the associated links to the gerrit patches below: --- The matching implementation is now selected dynamically during runtime. In order to be sure that the convolution part did not break, I wrote a small test program to compute some testvectors. I compared the results before and after my changes. They match up. I made only minimal changes to the conversion code, so I skipped testing that as well. The SSE relevant sources are compiled with $(SIMD_FLAGS) now. The sources only contain the SSE implementation and the decision logic to defer to the correct implementation during runtime. That should run fine on non SSE3 / SSE4.1 CPUs, since the decision logic is not vectorize-able. However, we can divide this up further as discussed. https://gerrit.osmocom.org/2098 buildenv: Turn off native architecture builds https://gerrit.osmocom.org/2099 cosmetic: Make parameter lists uniform https://gerrit.osmocom.org/2100 ssedetect: Add runtime CPU detection https://gerrit.osmocom.org/2101 cosmetic: Add info about SSE support https://gerrit.osmocom.org/2102 buildenv: Make build CPU invariant https://gerrit.osmocom.org/2103 cosmetic: remove code duplication https://gerrit.osmocom.org/2104 Add test program to verify convolution implementation --- -- - 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

Re: [MERGED] openbsc[master]: gprs_sgsn.c: initialize ptmsi with 0xdeadbeef
by Neels Hofmeyr 16 Mar '17

16 Mar '17

> - uint32_t ptmsi; > + uint32_t ptmsi = 0xdeadbeef; GSM_RESERVED_TMSI would make more sense here I guess (the "invalid TMSI" value). ~N

1 0

Re: Build failure of network:osmocom:nightly/libosmocore in xUbuntu_16.10/i586
by Neels Hofmeyr 16 Mar '17

16 Mar '17

should be fixed by https://gerrit.osmocom.org/2089 On Wed, Mar 15, 2017 at 07:52:33PM +0000, OBS Notification wrote: > Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/l… > > Package network:osmocom:nightly/libosmocore failed to build in xUbuntu_16.10/i586 > > Check out the package for editing: > osc checkout network:osmocom:nightly libosmocore > > Last lines of build log: > [ 143s] RAND: 6a61050765caa32c90371370e5d6dc2d > [ 143s] -AUTN: afb993e4f4b8000069cdeebb4a4b5b58 > [ 144s] +AUTN: 504693e4f4b80000e3963072c50f0b91 > [ 144s] IK: c348c2fe2f3e1fb37a7ae1638163bd98 > [ 144s] CK: e740c156278705a14e1a99ba6d31334f > [ 144s] RES: 7c04e86a67967fcd > [ 144s] SRES: 1b9297a7 > [ 144s] Kc: 10687b71e4eb94c5 > [ 144s] -SQN: 281474976710655 > [ 144s] +SQN: 4294967295 > [ 144s] > [ 144s] > [ 144s] > osmo-auc-gen -3 -a milenage -r 39fa2f4e3d523d8619a73b4f65c3e14d -k EB215756028D60E3275E613320AEC880 -o FB2A3D1B360F599ABAB99DB8669F8308 -A 979498b1f72d3e28c59fa2e72f9c > [ 144s] 40. testsuite.at:253: 40. osmo-auc-gen (testsuite.at:253): FAILED (testsuite.at:257) > [ 144s] debian/rules:26: recipe for target 'override_dh_auto_test' failed > [ 144s] make[1]: *** [override_dh_auto_test] Error 1 > [ 144s] make[1]: Leaving directory '/usr/src/packages/BUILD' > [ 144s] debian/rules:15: recipe for target 'build' failed > [ 144s] make: *** [build] Error 2 > [ 144s] dpkg-buildpackage: error: debian/rules build gave error exit status 2 > [ 144s] > [ 144s] build85 failed "build libosmocore_0.9.6.20170315.dsc" at Wed Mar 15 19:52:15 UTC 2017. > [ 144s] > [ 144s] ### VM INTERACTION START ### > [ 146s] [ 136.282415] reboot: Power down > [ 147s] ### VM INTERACTION END ### > [ 147s] > [ 147s] build85 failed "build libosmocore_0.9.6.20170315.dsc" at Wed Mar 15 19:52:19 UTC 2017. > [ 147s] > > -- > Configure notifications at https://build.opensuse.org/user/notifications > openSUSE Build Service (https://build.opensuse.org/)

1 0

NITB: high cpu usage and "crossed" messages when SMS table grows
by Keith 15 Mar '17

15 Mar '17

Hi all, I temporarily disabled a cron job we run at rhizomatica that purges the hlr SMS table of sent messages every day. After a few days I noticed slightly sluggish behaviour in the VTY, and sure enough, the nitb was consuming 100% cpu, not always, but presumably whenever it does a queue run. I also just heard that in the last few days, we got a number of reports from users, some confirmed by photos of the phones, about messages being delivered to the wrong destination. Apologies if this has been touched on before. I am not finding where I can directly search this list archives. Anyway, it might not be so bad to bring it up, as the cron job purging via cron job calling sqlite3 is not ideal, and anyway.. this crossed messages shouldn't happen, right? I imagine we'd like to track this one down. Keith.

4 7

osmo-bts-trx channel activation
by Max 14 Mar '17

14 Mar '17

Hi. This has been asked last year but to no avail, let's try again. How logical channels are (de)activated in osmo-bts-trx? For example in all the other models there's sapi_deactivate_cb() callback but osmo-bts-trx doesn't seem to be using sapi_cmd at all. To put this into perspective - while working on https://projects.osmocom.org/issues/1575 I got to activate/deactivate lchans when SI3 is received. This already works for sysmobts but I'd like to do the same for osmo-bts-trx as well. Is there any documentation somewhere describing how it works there? Or maybe someone more familiar with the code could help to shed the light on it? -- 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

autoconf and .deb question
by Max 14 Mar '17

14 Mar '17

Hi. There's strange thing about the way autoconf and debian/rules interact for OpenBSC: - in openbsc/include/openbsc/Makefile.am gsm_data_shared.h and common_cs.h are in noinst_HEADERS - in debian/openbsc-dev.install they are marked for installation And this actually works! If you run "dpkg-buildpackage -uc -us -tc" you'll get openbsc-dev*.deb with those headers properly installed. It's nice but feels a bit too much like magic. Any ideas how dh_install (or smth else?) manages to work around it? Should we be worried that it might break some time in future? Should we move those headers away from noinst_* section? -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC March 2017