OpenBSC November 2017

openbsc@lists.osmocom.org

21 participants
49 discussions

Re: Osmo-bts.cfg Open-bsc.cfg tutorial
by Vadim Yanitskiy 23 Nov '17

23 Nov '17

Hi, > I read a tutorial called "CalypsoBTS" The tutorial has been updated. Check out a new version please. https://osmocom.org/projects/baseband/wiki/CalypsoBTS > *There is no such command. Error occurred during reading > the below line: fn-advance 30*". How to fix it? Are there > any tutorials for beginners how configure these > "Osmo-bts.cfg" "Open-bsc.cfg" files? The configuration suggested by the previous version of this tutorial is obsolete. I may find the actual configuration examples in 'doc/examples/' of almost each project. With best regards, Vadim Yanitskiy.

1 0

Osmo-bts.cfg Open-bsc.cfg tutorial
by GSK MOSS 22 Nov '17

22 Nov '17

Hello! I read a tutorial called "CalypsoBTS" ( http://osmocom.org/projects/baseband/wiki/CalypsoBTS). Everything was good before I ran "Osmo-bts.cfg". I got a error : " *There is no such command. Error occurred during reading the below line: fn-advance 30*". How to fix it? Are there any tutorials for beginners how configure these "Osmo-bts.cfg" "Open-bsc.cfg" files? I need just to run "fake base station" for testing android app. Is there any another ways to run it with motorola? Thanks!

1 0

/usr/bin/lc15bts-mgr can't find GPS 3D fix to for calibration
by Rayan Salhab 22 Nov '17

22 Nov '17

Hi, We have a Litecell 1.5 unit. It is updated to the latest packages on the nightly build and configured to an osmo-bsc set up on an another machine. On mobile phones, the network does not show the short or long name set, instead it shows just numbers "09070" and calls can not be made. This has happened to us before when there was problem with the clock calibration on the BTS. A GPS device is attached to the BTS, and when running cgps, there is a 3D Fix and a correct GPS location coordinates show up. The lc15 bts should be able to calibrate automatically using the lc15bts-mgr package, however, it seems like it is failing to do so. When we tried stopping the lc15bts-mgr service and start it manually to log the output by running: /usr/bin/lc15bts-mgr -s -c /etc/osmocom/lc15bts-mgr.cfg We notice the following errors: ``` Failed to open /mnt/storage/var/run/lc15bts-mgr/volt-supply-max due to 'No such file or directory' error <0000> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_misc.c:315 Total hours of Operation: 393 <0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:271 Going to calibrate the system. <0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:121 Last GPS 3D fix can not read (-2). Last GPS 3D fix sets to zero <0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:126 GPS has no fix <0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:126 Going to check for watchdog notification. <0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:67 Missing watchdog events: e:0x000000000000002e,m:0x000000000000007f <0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:126 Going to check for watchdog notification. <0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:67 Missing watchdog events: e:0x000000000000002f,m:0x000000000000007f <0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:271 Going to calibrate the system. <0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:121 Last GPS 3D fix can not read (-2). Last GPS 3D fix sets to zero <0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:126 GPS has no fix <0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:126 Going to check for watchdog notification. <0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:67 Missing watchdog events: e:0x000000000000002f,m:0x000000000000007f ``` It seems the lc15bts_mgr service can not read the values from the GPS device for some reason, can someone please advise what might be causing this issue? Best Regards, Rayan

1 0

[osmo-hlr 0.1.0.7-8db4] testsuite: 4 failed
by Dees 21 Nov '17

21 Nov '17

Hi All, Was trying to build osmocom 3g system. Its failing in running test on osmo-hlr, any clues? ## --------------------------------- #### osmo-hlr 0.1.0.7-8db4 test suite. #### --------------------------------- ## Regression tests. 1: auc ok 2: auc_ts_55_205_test_sets ok 3: gsup_server ok 4: db FAILED (testsuite.at:30) ## ------------- #### Test results. #### ------------- ## ERROR: All 4 tests were run,1 failed unexpectedly.

2 3

why osmo-hnbgw doesn't build for me, and remaining puzzle
by Neels Hofmeyr 21 Nov '17

21 Nov '17

Ever since I upgraded to debian 9, osmo-hnbgw failed to link in my build: /usr/bin/ld: hnbgw.o: undefined reference to symbol 'sctp_send@@VERS_1' I noticed that adding -lsctp to the build fixed that, yet noticed that no build slaves nor anyone else seemed to need that. Some events coincided my re-install of deb9: - There has always been an -lsctp in the Makefile.am for osmo-hnbgw, but it was recently dropped in http://git.osmocom.org/osmo-iuh/commit/?id=7235ea02d78299471d58f4202d8c8d68… - I adopted the jenkins.sh -Werror flags in some builds to get fatal warnings. Passed by './configure CFLAGS=-Werror'. Someone else added this in jenkins.sh and I assumed that was a good way to do things. - I noticed that I couldn't see debug symbols in gdb, so added 'CLFAGS=-g' in my builds. read on... Comparing with a docker build kindly provided by laforge, I noticed that a plain 'clone; ./configure; make' does actually succeed on my system! It is a convolution of CFLAGS causing the error. By passing a 'CFLAGS=foo' to the osmo-iuh configure script, not only do I add 'foo', but I override CFLAGS defaults, and actually *remove* other CFLAGS. Turns out, whether I pass CFLAGS=-g or not, -g is always part of the build command lines: '-g -O2' is the default. Funnily enough, with CFLAGS=-g passed, I end up removing the -O2 option. A conclusion here is that in jenkins.sh, we should *not* pass CFLAGS to configure, so that we don't override any default CFLAGS. A configure option like --with-strict-warnings can add to CFLAGS in configure.ac instead So now I guess because I added CFLAGS=-Werror before, I ended up removing -g. Hence I saw a need to add -g again, goof. Did so in all builds while I was at it, hence -g ended up in osmo-iuh as well. The -g stuck around, and building osmo-iuh with CFLAGS=-g does, as I already said, effectively remove the -O2 option for all things built in osmo-iuh. Now I'm confused. Why does a lack of -O2 break a linkage. It's not the osmo-hnbgw linkage per se that seems to be the cause. I can link that last step with or without -O2 successfully. It must be a combination of building a depending library without -O2 and then linking that to osmo-iuh. I diffed the entire build log between a succeeding and a failing build of osmo-iuh, and really the only difference everywhere is that the succeeding build uses -O2 everywhere. The only differences in config.log are the same: most conftest programs have -O2 removed, few have a -g added. The conftest conclusions are all identical. My big question now is: sctp_send() is actually called from hnbgw.c directly. So IIUC, we should in fact be required to pass -lsctp to the linker for osmo-hnbgw. If that is correct, how am I allowed to skip that by passing -O2? That's all I figured out so far. I still would like to find out why this can happen, any ideas would be appreciated. Anyone should be able to reproduce this by building osmo-iuh with ./configure CFLAGS=-g ~N

2 2

LOGPFSM
by Neels Hofmeyr 20 Nov '17

20 Nov '17

Hi dexter, I just noticed this patch that is merged, with the lines + LOGPFSML(reset->fsm, LOGL_NOTICE, "fsm-state (msc-reset): %s, fsm-event: %s\n", get_value_string(fsm_state_names, ST_CONN), get_value_string(fsm_evt_names, event)); If you take a look at the log output this produces, you should see that LOGPFSM already contains information that it is an FSM, which state it is in, and that just before that an FSM event has fired. This log statement seems obsolete? Here's an example where you did everything right, just add a message to the FSM logging: + LOGPFSML(reset->fsm, LOGL_NOTICE, "SIGTRAN connection down, reconnecting...\n"); I marked in the (merged) patch those logging lines that seem to merely duplicate what we already see in the logs: https://gerrit.osmocom.org/4754 ~N

1 0

osmo-mgw endpoint allocation
by Harald Welte 20 Nov '17

20 Nov '17

Hi all, we recently had some (verbal) discussions on how to handle endpoint allocations in a scenario where a single osmo-mgw shall be used by both osmo-bsc and osmo-msc (in a "NITB style" setup). There was some thinking about whether we should somehow divide fixed ranges of the rtp-bridge endpoints between the BSC and the MSC and how to avoid having to manually configure those. I think I now found the proper solution for this: The call agent must not even fully qualify the endpoint, but it can ask the MGW to allocate one! To quote from the MGCP RFC: EndpointId is the identifier for the connection endpoint in the gateway where CreateConnection executes. The EndpointId can be fully-specified by assigning a value to the parameter EndpointId in the function call or it may be under-specified by using the "any of" wildcard convention. If the endpoint is underspecified, the endpoint identifier SHALL be assigned by the gateway and its complete value returned in the SpecificEndPointId parameter of the response. When the "any of" wildcard is used, the endpoint assigned MUST be in- service and MUST NOT already have any connections on it. If no such endpoint is available, error code 410 (no endpoint available) SHOULD be returned. The "all of" wildcard MUST NOT be used. So in our concrete example, the BSC (or MSC) could simply ask for "rtpbridge/*@mgw" as end-point name in CRCX, and the MGW would then dynamically allocate a suitable free rtpbridge endpoint type and return it in the call agent in the BSC (or MSC). No shared knowledge about endpoint number allocations / ranges or the like required. Now we only need to implement this in osmo-mgw ;) Related: https://osmocom.org/issues/2631 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

simtrace at use
by Max 20 Nov '17

20 Nov '17

Hi. I've stumbled upon awesome hack which seems to be relevant: https://ha.cking.ch/s8_data_line_locator/ It uses Simtrace to check how hw implant communicates with its sim. The guy also tried to sniff GPRS traffic but failed (because he've used OpenBTS, he-he :) - I wonder if it would work better with OsmoBTS. Anyone else played with similar device already? -- 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

1 0

news for sanitizer builds
by Neels Hofmeyr 19 Nov '17

19 Nov '17

I recently found sanitizer build failures, for example in libosmocore, which our gerrit build job doesn't catch. At first I thought something was amiss and maybe our gerrit sanitizer build were broken. Instead, it turns out my debian9 gcc -fsanitize=address -fsanitize=undefined finds many more issues that the debian8 one does not. https://jenkins.osmocom.org/jenkins/job/gerrit-libosmocore/36/a2=default,a3… I already have a long series for mem leak fixes for libosmocore, mostly in the regression testing code, but I count three real mem leak fixes in libosmocore production code. My plan is to merge the fixes and then actually move the libosmocore-gerrit to debian 9 (or at least add debian 9) to make sure we don't add insanities that the debian 9 build would find. See https://gerrit.osmocom.org/4861 to https://gerrit.osmocom.org/4875. I'm also taking a look at the other CellNet builds. The root motivation was to find out why osmo-hnbgw doesn't work for me anymore currently. ~N

3 3

osmo_fsm timer_cb fudge up
by Neels Hofmeyr 18 Nov '17

18 Nov '17

I'm finding heap use after free related to osmo_fsm: - When dispatching a timer_cb event, we want to set fi->T back to 0. (see fsm_tmr_cb()) - So that we know which timer fired, we leave fi->T at its current value for the timer_cb to be able to make decisions based on that. This is used for example in fsm_timeout_cb() in osmo-bsc/osmo_bsc_mgcp.c. - In other code, the timer_cb event may decide to fire events or call functions which effect an FSM instance teardown and deallocation, meaning that in fsm_tmr_cb(), we are *not* allowed to generally assume the fi still exists. If we set fi->T = 0 after the timer_cb() was called, we may write to freed mem. - Also, if the timer_cb effects events with their own timeout, we will also overwrite the fi->T value with zero after another timer has set its value in T, causing failures to evaluate that timer later on. Solutions so far: - set fi->T = 0 first, and pass T to the timer_cb as arg instead. I think this is the best and cleanest, but also the hardest in terms of backwards compat. I have a patch that adds timer_cb2() that features a T arg; we need to submit that, move all code that wants to use T to that timer_cb2(), and then we can move the fi->T = 0 to before the timer_cb(). Actually, this is not being backwards compatible at all, because all code trying to use fi->T as usual will need adjustment, we break API either way and might as well add T to the timer_cb directly instead... :/ - Actually not set fi->T = 0 at all. We will have T holding the value of the timer that fired last, all old code will still find this T in fi->T, and after the cb, we just leave it as it was. Does it really need to be cleared? This has no compatibility issues and solves the use after free as well as setting a new T from timer_cb() issues. Going for this one so far. Thoughts? ~N

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2017