- OpenBSC - lists.osmocom.org

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

18 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

Re: libosmocore and SSE
by Vadim Yanitskiy 15 Aug '17

15 Aug '17

Hi Neels and Harald, Is the problem related to an issue, reported by Max? https://osmocom.org/issues/2386 As I already commented, there is one possible reason: Currently, the conv_acc_sse.c is being compiled with both -msse3 -msse4.1 CFLAGS. Some compilers (or different versions) may use the msse4.1 instruction set to optimize the whole byte code, even in the places where they are not actually used. So, one possible solution is to separate the conv_acc_sse.c to conv_acc_sse_3.c and conv_acc_sse_41.c, and then compile them with -msse3 -msse4.1 flags respectively. If I had some basic compile / check access to the build host, I could check whether my assumption is correct. With best regards, Vadim Yanitskiy.

3 2

Re: Build failure of network:osmocom:nightly/openbsc in Debian_9.0/x86_64
by Neels Hofmeyr 14 Aug '17

14 Aug '17

We've seen the same in lynxis' debian builds of the split gits, and now it makes sense: The recent openggsn changes to debian rules somehow cause an oddity so that our configure check for libgtp now fails, causing all GPRS related binaries to not be built. Haven't investigated what exactly it is, but my expectation is that openggsn causes osmo-sgsn etc to fail: My guess is https://git.osmocom.org/openggsn/commit/?id=23eea1d132120198745dcca32728906… "Use osmocom-style git-version-gen / .version magic" (tagged 0.94) We try to find it by: PKG_CHECK_MODULES(LIBGTP, libgtp >= 0.92, , found_libgtp=no) log: [ 60s] [110/216] installing libgtp1-0.93.20170812 [...] [ 61s] [116/216] installing libgtp-dev-0.93.20170812 [...] [ 138s] checking for LIBGTP... no https://build.opensuse.org/public/build/network:osmocom:nightly/Debian_9.0/… ~N On Fri, Aug 11, 2017 at 08:04:10PM +0000, OBS Notification wrote: > Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o… > > Package network:osmocom:nightly/openbsc failed to build in Debian_9.0/x86_64 > > Check out the package for editing: > osc checkout network:osmocom:nightly openbsc > > Last lines of build log: > [ 176s] make[4]: Leaving directory '/usr/src/packages/BUILD/openbsc/tests' > [ 176s] make[3]: Leaving directory '/usr/src/packages/BUILD/openbsc/tests' > [ 176s] make[3]: Entering directory '/usr/src/packages/BUILD/openbsc' > [ 176s] make[4]: Entering directory '/usr/src/packages/BUILD/openbsc' > [ 176s] make[4]: Nothing to be done for 'install-exec-am'. > [ 176s] /bin/mkdir -p '/usr/src/packages/BUILD/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig' > [ 176s] /usr/bin/install -c -m 644 openbsc.pc '/usr/src/packages/BUILD/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig' > [ 176s] make[4]: Leaving directory '/usr/src/packages/BUILD/openbsc' > [ 176s] make[3]: Leaving directory '/usr/src/packages/BUILD/openbsc' > [ 176s] make[2]: Leaving directory '/usr/src/packages/BUILD/openbsc' > [ 176s] make[1]: Leaving directory '/usr/src/packages/BUILD/openbsc' > [ 176s] dh_install -O--sourcedirectory=openbsc > [ 176s] dh_install: Cannot find (any matches for) "/usr/bin/osmo-sgsn" (tried in "." and "debian/tmp") > [ 176s] dh_install: osmocom-sgsn missing files: /usr/bin/osmo-sgsn > [ 176s] dh_install: Cannot find (any matches for) "/usr/bin/osmo-gtphub" (tried in "." and "debian/tmp") > [ 176s] dh_install: osmo-gtphub missing files: /usr/bin/osmo-gtphub > [ 176s] dh_install: missing files, aborting > [ 176s] debian/rules:13: recipe for target 'binary' failed > [ 176s] make: *** [binary] Error 2 > [ 176s] dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 > [ 176s] > [ 176s] lamb17 failed "build openbsc_0.15.1.20170811.dsc" at Fri Aug 11 20:03:59 UTC 2017. > [ 176s] > [ 176s] ### VM INTERACTION START ### > [ 180s] [ 168.503704] reboot: Power down > [ 180s] ### VM INTERACTION END ### > [ 180s] > [ 180s] lamb17 failed "build openbsc_0.15.1.20170811.dsc" at Fri Aug 11 20:04:03 UTC 2017. > [ 180s] > > -- > Configure notifications at https://build.opensuse.org/user/notifications > openSUSE Build Service (https://build.opensuse.org/) -- - 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

libosmocore and SSE
by Neels Hofmeyr 13 Aug '17

13 Aug '17

We notice that when libosmocore debian packages built on opensuse.org end up on the cumulus3 host, we get /usr/src/packages/BUILD/tests/testsuite.dir/at-groups/9/test-source: line 25: 26402 Illegal instruction $abs_top_builddir/tests/conv/conv_gsm0503_test (unfortunately I have no full logs, they were rotated away) All other hosts we hit so far apparently work fine. a) debian packages should be usable on the largest set of CPUs, we should not build with CPU instructions we can't guarantee to be supported. So I guess we need a --without-sse configure option in libosmocore. Makes sense? b) I'm puzzled that the same host that built conv_gsm0503_test fails to run it. Is our SSE check in libosmocore's configure.ac broken? How to verify? c) would be nice to find out what kind of host cumulus3 is; so far we know only that it is an x86_64. https://build.opensuse.org/monitor Ideas? Experience? ~N

2 3

Support for SMPP Delivery Receipt / GSM03.40 Status Report in master
by Pablo Neira Ayuso 11 Aug '17

11 Aug '17

Hi! Support for SMPP Delivery Receipt / GSM03.40 Status Report has been now merged into master. If you developed your own ESME, this may require changes on your side so things doesn't break. Basically, you have to make sure your ESME deals with esm_class = Delivery Receipt SMPP messages. MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | SMS-DELIVER | | |<----------------------------| | | GSM 04.11 RP-ACK | | |---------------------------->| | | | DELIVER-SM | | | esm_class = Delivery Receipt | | |------------------------------->| | | DELIVER-SM-RESP | | |<-------------------------------| | | | In a nutshell: Your ESME should not assume a DELIVER-SM always convey a SMS, so such DELIVER-SM should NOT be bounced back to the corresponding SMSC as a normal SUBMIT-SM since it does not represent a SMS. Your ESME also needs to send a Delivery Acknowledgement to the mobile station of origin, the one that sent the SMS, so the SMSC can deliver the corresponding GSM03.40 SMS-STATUS-REPORT. MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | | SUBMIT-SM | | | esm_class = Delivery Ack | | |<-------------------------------| | | SUBMIT-SM-RESP | | |------------------------------->| | | | | SMS-STATUS-REPORT | | |<----------------------------| | | GSM 04.11 RP-ACK | | |---------------------------->| | | | | Please, see at recent updates on utils/smpp_mirror.c, I made a number of small patches so I could this utility to test my patches that, I think, should be help understand the changes that you have to do on your ESME: http://git.osmocom.org/openbsc/log/openbsc/src/utils/smpp_mirror.c Let me know if you have any question/concern. Thanks!

1 0

Ring Back Tone Missing during Call Setup
by Ron 11 Aug '17

11 Aug '17

Hi All, I’m not sure if this is a valid question but still I’m going to try. I just updated from my old version of OSMOCOM to the latest one. Upon trying to test the updated version, it seems that the ring back tone, the one that rings in the Caller (Anum/Mobile Originating) side if the call started to ring on the Callee (BNUM/Mobile Terminating) side, is missing. Can anyone direct me to the right path where to check it? Below are the configuration files used for each OSMOCOM elements. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

2 5

gerrit review comments
by Neels Hofmeyr 10 Aug '17

10 Aug '17

Again it is brought to my attention that my gerrit review causes annoyance. There is a recurring theme here, so I'd like to address all patch submitters. I feel like it's a Good Thing to mark *everything* I notice: "I've read your patch, and these are all the details I found, in case you'd like to address them." I see it as a courtesy towards the patch submitter. For some reason though I turn out to upset rather than help?? My (wrong?) impression is that these are normal reviews as I've given them as well as received them hundreds of times over the last decade+. In my world, adjusting my patches N times is normal, I make mistakes all the time. But I certainly don't want to upset: I'd really like to find out what I can change to make everyone's hacking smoother. In all my previous projects I got used to very high code scrutiny, and when starting on Osmocom, Holger's review of my patches has continued on the same high level ... often I had to revisit large amounts of my code. Thus primed, I find it hard to ignore irregularities: most of them mean the code becomes less stable or less maintainable/readable. Usually I'm trying to understand what the patch does or intends, and want to make sure future readers of the code can also understand easily. The idea is to save time in the long run. If you disagree with me or see inconsistencies, please let me know, whether a patch is merged or not. Maybe I oversaw something or maybe I'm just plain wrong. The mood I'd like to convey is: "yes, I trust you that all these patches are an improvement. I invested some of my time in your work with the goal to merge it soon. And here's everything that caught my attention; do you agree?" Ideally we can reach high code standards and at the same time collaborate productively. None of my gerrit comments or -1 votes are intended to convey emotion... Feel free to mail or jabber or talk to me, also privately, on these issues anytime! And feel free to ignore nitpicks if you don't care enough. ~N

1 0

ip.access nano 3.5G : Any advice on how to configure channel and power?
by Alan Evans 09 Aug '17

09 Aug '17

Hello devs, I am using a 3.5G nano starter kit and I have a problem, hopefully someone can give me some advice. When I use the kit in a location with very little 3G coverage it works great, I scan for 3G networks, the phone sees a network '90170' and can register without any problems. However if I try the same thing in a location that has very good macro 3G coverage from several network operators, the phone can longer see my nano cell. I assume the problem is due to frequency reuse and the nanocell is using the same UARFCN as one of the macro cells. Does anyone have any advice on how best to find a clear frequency band to use? Also does anyone know if I have to reboot the ip.access after changing the UARFCN using set rfParamsCandidateList=({9800, 401, 1}) Regards -- Alan R Evans KAGE Design Services Ltd Tel: +44 7891 773415 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1