OpenBSC November 2017

openbsc@lists.osmocom.org

21 participants
43 discussions

default point codes
by Neels Hofmeyr 24 Nov '17

24 Nov '17

Looking at https://osmocom.org/projects/cellular-infrastructure/wiki/Point_Codes OsmoMSC currently uses 0.23.1 for A-and-Iu, and 0.23.2 for Iu only if Iu is on a different cs7 instance than A (i.e. practically never). Either way that doesn't really make sense to me. If OsmoMSC is connecting to the same STP for A and Iu, it is sufficient to have one point-code for the two SSNs for A (BSSAP) and Iu (RANAP) and hence use one cs7 instance for both. If it is connecting to two different STPs, the point codes do not collide anyway, and it makes no sense to use a different one for Iu. It only confuses the defaults, e.g. the wiki page was wrong until I fixed it just now. I would rather have just 0.23.1 for the MSC for all SSNs. See ss7_setup() in msc_main.c. Agreed? ~N

2 2

osmo-bts-trx init problem
by GSK MOSS 23 Nov '17

23 Nov '17

Hello! I got this problem: *root@pc:~/osmocom# osmo-bts-trx -c ~/.osmocom/osmo-bts.cfg((*)) | / \ OsmoBTS<0017> control_if.c:828 CTRL at 127.0.0.1 4238<0010> telnet_interface.c:104 telnet at 127.0.0.1 4241<0012> input/ipaccess.c:886 enabling ipaccess BTS mode, OML connecting to 127.0.0.1:3002 <http://127.0.0.1:3002><000b> trx_if.c:595 Open transceiver for phy0.0<0012> input/ipa.c:129 connection done.<0012> input/ipaccess.c:707 received ID get<0001> oml.c:229 O&M Get Attributes [0], Manufacturer Dependent State is unsupported by TRX.<0001> oml.c:680 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug!<0001> oml.c:680 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug!<0001> oml.c:680 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug!<0001> oml.c:680 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug!<0001> oml.c:680 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug!<0001> oml.c:680 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug!<0001> oml.c:680 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug!<0001> oml.c:1049 ADM state already was Unlocked<0012> input/ipa.c:129 connection done.<0012> input/ipaccess.c:707 received ID get* *<000b> trx_if.c:409 transceiver (phy0.0) rejected TRX command with response: 'RSP SETTSC -1'* *<0001> bts.c:210 Shutting down BTS 0, Reason TRX-CTRL-MSG: CRITICAL* *<0007> l1sap.c:462 Invalid condition detected: Frame difference is 2452951-0 > 1!* *Shutdown timer expired* What is the problem and how can fix it? I used 1 phone and cfg files (from this tutorial https://osmocom.org/projects/baseband/wiki/CalypsoBTS): - OsmoNITB: 'doc/examples/osmo-nitb/sysmobts/openbsc.cfg' - OsmoBTS: 'doc/examples/trx/osmo-bts.cfg' thanks!

2 1

RFC: new type for NAS/EPS in gsmtap.h and question
by Shinjo Park 23 Nov '17

23 Nov '17

Hi list, While I was experimenting with osmo-qcdiag and other LTE stuff, I want to add NAS/EPS as a new payload type for gsmtap.h. Unlike GSM and UMTS, LTE introduced separate layer for encryption of NAS and RRC. As a result, while NAS messages are piggybacked to LTE RRC, but after NAS security had been activated only encrypted NAS messages are available at RRC layer. This is reflected into the baseband diagnostics of various makers: Qualcomm provides separate diagnostic item for LTE NAS (both encrypted and plain) and RRC. Separate payload type for LTE RRC and LTE NAS will solve this issue. I can submit a patch if this looks positive. Also, I have a question regarding ARFCN field. Currently (in version 2) ARFCN is a 16-bit integer, with 2-bit of flags (PCS band, uplink) therefore making 14-bits available for raw value. This causes some problem in LTE: 1) EARFCNs for uplink are starting from 18000, which is larger than 2^14 2) There are EARFCNs even larger than 2^16 (Bands 65+, LTE-U frequencies) 3) No separate indicator for ARFCNs used by UMTS/LTE-TDD network Also in UMTS, there are overlapping UARFCNs between bands, which necessitates a separate field for band indicator. Changes regarding these will break the GSMTAP header structure, therefore I want to discuss about how these could be addressed. Best Regards, Shinjo -- Shinjo Park <pshinjo(a)sec.t-labs.tu-berlin.de> Security in Telecommunications <sec.t-labs.tu-berlin.de> TU Berlin / Telekom Innovation Laboratories Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany Phone: +49 30 8353 58272

2 1

Re: RFC: new type for NAS/EPS in gsmtap.h and question
by Martin Heusse 23 Nov '17

23 Nov '17

Hi, working on a diagnostic interface, I also ran into the lack of a gsmtap type for LTE NAS plain messages. So I am supporting Shinzo's request for a new GSMTAP_TYPE_LTE_NAS (or GSMTAP_TYPE_LTE_UU) type in packet-gsmtap.h. This type would play a similar role to that of GSMTAP_TYPE_UM for GSM, if my understanding is correct. Best regards, Martin > Unlike GSM and UMTS, LTE introduced separate layer for encryption of NAS and > RRC. As a result, while NAS messages are piggybacked to LTE RRC, but after NAS > security had been activated only encrypted NAS messages are available at RRC > layer. This is reflected into the baseband diagnostics of various makers: > Qualcomm provides separate diagnostic item for LTE NAS (both encrypted and > plain) and RRC. Separate payload type for LTE RRC and LTE NAS will solve this > issue. I can submit a patch if this looks positive. > >

2 1

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2017