December 2016 - OpenBSC - lists.osmocom.org

ki in osmo-nitb's built-in HLR db
by Neels Hofmeyr 25 Dec '16

25 Dec '16

Merry x-mas! Just now I found a curious problem with the current osmo-nitb ciphering key. I'm working on the new VLR, which will inherently fix this issue, but in the course of that I recapped the current osmo-nitb's sequence of events for 2G ciphering as it is on the openbsc master branch. It so happens that I'm using a SIM card with a fabricated Ki value of hex: 000102030405060708090a0b0c0d0e0f i.e. starting with a zero byte. I was able to store this in and retrieve from the hlr.sqlite3 db: sqlite> INSERT INTO "AuthKeys" VALUES(57,2,X'000102030405060708090A0B0C0D0E0F'); sqlite> select hex(a3a8_ki) from AuthKeys; 000102030405060708090A0B0C0D0E0F So there were 16 bytes worth of BLOB in the Ki column for sure. But in openbsc's db.c in db_get_authinfo_for_subscr(), I always got DMM <0002> ../../../src/libmsc/auth.c:70 Invalid COMP128v1 key (len=0) Curious, could it be the zero byte? Just to check, I put the zero byte further left: sqlite> select hex(a3a8_ki) from AuthKeys; hex(a3a8_ki) F00102030405060008090A0B0C0D0E ^ nonzero ^^ zero Now the log says: DMM <0002> ../../../src/libmsc/auth.c:70 Invalid COMP128v1 key (len=5) f1 f3 f4 f5 f6 That's even weirder. I was expecting a 7 byte BLOB, of f0 01 02 03 04 05 06 and not f1 f3 f4 f5 f6 ... what on earth ... It appears that we've so far always been unable to use Ki keys that contain a zero byte, or apparently anything that's outside the 7bit ascii space ... ? To be able to recap what the old osmo-nitb is doing (without going to fetch a card reader from the office and reprogram the Ki on the SIM card), I fixed this bug with this funny little hack: https://gerrit.osmocom.org/1504 Todo: are other BLOB values also affected? Is there a better way to fix? Even though the new VLR is on its way, it might be good to get a fix like this out in the meantime ... though it appears that no-one is using ciphering on 2G anyway? ~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

2 3

Debugging osmo-trx constellation on XTRX SDR
by Alexander Chemeris 24 Dec '16

24 Dec '16

Hi Thomas, We're porting osmo-trx to our XTRX and we see some weird constellation (https://goo.gl/photos/1KycUsv26Z6T6aN97) It looks like a normal GMSK circle is there, but there is also a square like if a signal is clipped. Do you have any idea what could cause this from your previous experience? We're running osmo-trx at 4 SPS. Then we double sample rate in software (XTRX can't handle sample rates below 2 MSPS yet) and then transmit. See first image above. Then we tried to increase sample rate and enabled 4x interpolation in LMS7 - that led to a distorted cicrle + square constellation (https://goo.gl/photos/zMZRecxmZsqiCYMHA) -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co

2 2

Error of skipping buffer data
by Mayuri Tendulkar 22 Dec '16

22 Dec '16

Hi Team Has anybody seen error like below while running osmo-stack on B210? What could be the reason of this failure? We are seeing this randomly. ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1039:check_rx_md_err: An internal receive buffer has filled at 31.9377 sec. ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer data: timestamp=8696668 time_end=8651398 ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer data: timestamp=8696668 time_end=8651398 ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer data: timestamp=8696668 time_end=8651398 ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer data: timestamp=8696668 time_end=8651398 NOTICE 140460079380224 20:17:34.0 Transceiver.cpp:306:stop: Stopping the transceiver ALERT 140460079314688 20:24:03.3 radioInterface.cpp:323:pullBuffer: Receive error 0 ERR 140460079314688 20:24:03.4 UHDDevice.cpp:1039:check_rx_md_err: An internal receive buffer has filled at 437.017 sec. Regards Mayuri

1 0

sporadic gerrit build job failue: "broken pipe"
by Neels Hofmeyr 21 Dec '16

21 Dec '16

We get this more often than not in the openbsc build job, I'm still not sure how to fix it: ====================================================================== ERROR: testBSCreload (__main__.TestVTYNAT) ---------------------------------------------------------------------- Traceback (most recent call last): File "./vty_test_runner.py", line 785, in testBSCreload b0 = nat_bsc_sock_test(0, "lol") File "./vty_test_runner.py", line 1276, in nat_bsc_sock_test ipa_handle_resp(bsc, tk, verbose) File "./vty_test_runner.py", line 1260, in ipa_handle_resp x.send(IPA().id_resp(IPA().identity(name = tk.encode('utf-8')))) error: [Errno 32] Broken pipe ---------------------------------------------------------------------- Ran 43 tests in 51.717s FAILED (errors=1) Reducing the nr of executors hasn't had an effect yet. Could there be another cause? Too fragile timing or something? ~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

2 4

indicating a necessary revision
by Neels Hofmeyr 19 Dec '16

19 Dec '16

When committing a change that needs a specific change from another project, but that other change is still in the gerrit queue and has no final git commit hash yet, it is handy to use the Change-Id to reference the given decision. Harald recently requested that I always include the Change-Id in the commit log. Now Max says: > It's better to update commit log with git commit hash instead of change-id > before final submission. Can we get consensus? Should we modify the commit log from Change-Id to git hash once the required other commit is through? The Change-Id is always there and can be searched for in the git log; and should we ever decide to rehash the git history or move to another version control software (losing all git hashes), the Change-Id would still be there. But the git hash, once it is finalized, can be used directly on the git commandline. I wouldn't have done the extra effort, but if all agree that the git hash is better, I'll change it (and hopefully remember to do it, too). ~N

1 0

osmo-iuh-3G_2016_09
by Radiarisainana Sitraka 19 Dec '16

19 Dec '16

Hello, I have some question, is it possible to run osmo-iuh with the vodafone signal secure 3 !? or should I root it !? Chears,

2 1

libosmocore changes / release process
by Neels Hofmeyr 18 Dec '16

18 Dec '16

When I now change pretty much anything in libosmocore that I want to use in e.g. openbsc.git, I would like to bump the minor revision and reference that in other projects' configure.ac. The effort is ok if it entails only tagging a revision and using that elsewhere. However, this has come down to a lengthy process: " cleanup TODO-RELEASE file if not empty, bumping API versions accordingly (see comments in TODO-RELEASE) update debian/changelog using "gbp dch" command " https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_releas… So, pretty much every commit in libosmocore will be followed by another commit that is adjusting the changelog...? :/ Should we adjust the changelog along with pretty much any change used outside of libosmocore? :/ (probably not, because reverting anything is made cumbersome) Should we rather, like, make a libosmocore release only once a week and somehow track wich other projects need a bump to the required libosmocore version? I think most projects out there make a release tag only every now and then. We could limit to noting the required libosmocore change-id in other projects' commit logs until the next (minor) release is made...? Can we add a fourth level of version that doesn't require a changelog/debian release? So for every small change I make I would tag 0.9.6.1, 0.9.6.2, etc., and at some point we make 0.9.7 along with a changelog adjustment? Thoughts? ~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 7

reduce gerrit mails?
by Neels Hofmeyr 15 Dec '16

15 Dec '16

Hi Gerrit users, I follow the gerrit mails to get notified of comments and to catch failing builds. The message that a build started or was successful though doesn't help me much, only clutters up space, really. Do you agree? If yes, I would try to silence the "Build started" and "Build successful" messages in our gerrit, if possible without too much effort... ~N

3 5

[nhofmeyr@sysmocom.de: Re: Help required on : Reproducing the issue]
by Neels Hofmeyr 15 Dec '16

15 Dec '16

On Wed, Dec 14, 2016 at 02:24:23PM +0000, Pravin Kumaravel Manoharan wrote: > I tried to reproduce the issue mentioned in http://lists.osmocom.org/pipermail/openbsc/2016-December/009966.html . > While running sanitizer script I got an error gcc: error: unrecognized command line option '-fsanitize=undefined' > So, to avoid this I removed the option from CFLAGS+= and CXXFLAGS+= . That's odd, all compilers I've used so far apparently support -fsanitize=address -fsanitize=undefined anyway: > Then I got the following error : > ERROR: Address Sanitizer: heap-use-after-free on address 0x60380000a00c at pc 0x436acf bp 0x7ffc4456d4e0 sp 0x7ffc4456d4d8 > but I didn't get any SIGSEGV in sgsn_create_pdp_ctx(). Have you reversed the order of those two lines I wrote about earlier to fix the use-after-free yet? This is what I wrote: > I found a use-after-free which isn't the cause for above asan failure: > > gsm0408_gprs_access_cancelled(mm, GMM_CAUSE_GPRS_NOTALLOWED); > LOGMMCTXP(LOGL_NOTICE, mm, "No PDP context to deactivate\n"); > > gsm0408_gprs_access_cancelled() calls mm_ctx_cleanup_free(), and after that the > local mm is non-NULL but freed. Change the order to: > > LOGMMCTXP(LOGL_NOTICE, mm, "No PDP context to deactivate\n"); > gsm0408_gprs_access_cancelled(mm, GMM_CAUSE_GPRS_NOTALLOWED); > > (This second issue is shown when removing test_pdp_deactivation_with_pdp_ctx() > from test_pdp_deactivation()) If you do that, do you still get any asan errors? I hope that you'll be able to reproduce the segfault, since it was seen on both our build server as well as my own laptop... ~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 ----- End forwarded message ----- -- - 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

1 0

git tagging
by Max 14 Dec '16

14 Dec '16

Hi. With the migration to gerrit the situation around version tagging become even funnier than before. For example right now in libosmocore v0.9.3 does not exist as a git tag, only as entry in debian/changelog. Versions 0.9.5 and 0.9.6 are committed in reversed order - see output of git log --tags --show-notes --decorate | grep 'tag:' | head So the questions are: - how can I add tag '0.9.3' to commit abc46af90fde9e9435dee5f4f472aec3f68d3353 in libosmocore - how can we prevent the inverted commit situation as with 0.9.6 and 0.9.5 in future? - what's the general guidelines for tagging new versions? Do we go through gerrit or ask responsible person (who?) to do it manually? Or even auto-tag commit matching certain criteria? -- 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

3 4