OpenBSC August 2017

openbsc@lists.osmocom.org

19 participants
44 discussions

huge patches
by Neels Hofmeyr 16 Aug '17

16 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 13 Aug '17

13 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

paging priority
by robert 09 Aug '17

09 Aug '17

Hi, I have noticed that when there are many MS connecting to my BTS if I try to page (call or send SMS) a specific MS it takes a long time and sometimes just fails. Is there a way to give a higher priority for paging under high network loads ? from vty: Current Channel Load: CCCH+SDCCH4: 100% (4/4) TCH/F: 100% (2/2) SDCCH8: 100% (40/40) best regards,

3 3

Re: jenkins and osmo-ci
by Neels Hofmeyr 09 Aug '17

09 Aug '17

Hey André, since https://gerrit.osmocom.org/2465 is merged, do you have a patch ready that enables the build cache for openbsc.git/contrib/jenkins.sh? The slowness of the openbsc-gerrit builds is a drag... We could throw more build slaves at it, but it makes sense to give the build cache a chance first. ~N

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC August 2017