OpenBSC March 2017

openbsc@lists.osmocom.org

22 participants
52 discussions

about reusing subscriber connections
by Neels Hofmeyr 10 Mar '17

10 Mar '17

Testing with the nano3G, e.g. when sending a large SMS, I see that multiple CM Service Requests may come in on the same IuCS connection. The code so far assumed that a CM Service Request would always come in on a fresh, unauthenticated connection (after iuRelease): the ProcessAccessReQuest FSM always starts out with establishing identities, authentication, ciphering. Now I've added code to accept a CM Service Request on an already accepted connection, by sending back an immediate CM Service Accept without even invoking the PARQ FSM. But that might not be such a good idea: I face the same for a Location Updating. A phone may choose to send a periodic LU on an already open and accepted connection (I guess). So we should allow that by sending back a LU Accept right away, without another authentication dance. But we also want to tell the HLR about the LU. The VLR FSMs may also have other actions in mind that the MSC doesn't know or care about. So: To not re-invent the wheel outside of libvlr, I would go on and add a flag to the LU and PARQ FSMs to indicate that the request is coming in on an already accepted connection, to jump directly to the post-ciphering FSM state. But I'd like to hear whether you guys have some thoughts or experience on this. For the case of the large multi-part SMS, we usually are fast enough in releasing the conn after each SMS fragment. For the next fragment, another initialUE message with a CM Service Request starts the PARQ FSM, auth+ciph is re-established, and the next part goes through. But sometimes the UE has already started to send another CM Service Request to initiate the next SMS fragment before it acked the previous one -- meaning that before we get as far as being done and issuing an iuRelease from the CN, the UE already sends another fresh CM Service Request on the same conn. That means we don't have to re-establish auth, quite nice actually. To allow cascades like these, we might also decide to iuRelease slightly later, giving the UE another second to re-use the open connection, so that we have less message overhead and use less auth tuples -- I wouldn't actually give it much more than a second; after about five seconds, the UE usually does an iuRelease itself. That sounds sane, but actually https://osmocom.org/issues/1816 holds against that: when I send USSD requests *from the phone* rapidly without leaving time to iuRelease, only the first USSD goes through from the UE to the CN. The second one is never received on the IuCS wire. That would indicate that the phone expects a conn to close right away from the CN, always. When I wait for iuRelease before sending another USSD, the MO USSD gets its own conn established and all is well. This behaves identically for both the femto cell kinds I have for testing. But, today, seeing multiple CM Service Requests on the same conn for SMS makes me think that #1816 might be a bug in the USSD dispatch of my phone. If MO SMS can do CM Service Requests on an already open conn, why should MO USSD not be able to do the same? I think in the old, pre-VLR code, we would accept multiple CM Service Requests on the same conn without problems, because the semantics were "re-entrant", calling secure_connection() in multiple places, which was skipped when some flag that we're already authenticated was set. The VLR paradigm is different: it "locks down" a new conn until that is accepted (authenticated and ciphered, according to config). Once a conn is accepted, the rest of the code does not need to bother with asking for securing a connection. So far receiving a CM Service Request is semantically identical with starting a new conn. That's why I would explicitly add a parameter to FSM invocation to skip over auth+ciph in case the conn is already accepted, but still do any HLR actions as needed. What still bugs me is: when the phone knows that a conn is open, why should it bother with a CM Service Request, it could just start sending the real meat right away. Re-using from the CN side: In https://osmocom.org/issues/1712#note-7 I noted that the code should not page when a connection is already open. https://osmocom.org/issues/1862 asks for not attempting to send USSD from the CN to the UE when a conn is there but not authenticated/ciphered yet. When the conn is accepted, we can immediately send the MT messages -- however, if the conn is there but still busy authenticating, we must neither page nor can we send messages right away. We should then add an item to the queue of actions to carry out after a paging response, without dispatching a paging request; and ensure that the queue is also worked off in case we receive a CM Service Request or LU Request instead of a Paging Response ... actually, this might already work, but I should test for it. P.S.: Also wondering, could it happen that we receive a Paging Response on an already accepted connection? Wouldn't make much sense, but might be possible to provoke ;) Any facts/thoughts on this stuff are welcome. ~N

1 0

Re: libosmocore build failure cascade
by Vadim Yanitskiy 09 Mar '17

09 Mar '17

Hi Neels, Max and others, Sorry, I didn't expect such build failures. It seems, some of them was already fixed before I noticed this mail. I was a bit busy with OsmoBTS testing, so let me some time to go through this issues and let me know, if I should fix something else. Before submitting a new change, I do the following: - make check - make distcheck Should I test something else in the future? With best regards, Vadim Yanitskiy.

3 2

Re: New Defects reported by Coverity Scan for Osmocom
by Neels Hofmeyr 09 Mar '17

09 Mar '17

From libosmo-abis beb10ef02a10d73537a97f6f21aad36664c9b266 "add basic unixsocket support": On Wed, Mar 08, 2017 at 08:39:07AM -0800, scan-admin(a)coverity.com wrote: > *** CID 163920: (TAINTED_SCALAR) > /source-Osmocom/libosmo-abis/src/input/unixsocket.c: 90 in unixsocket_read_cb() > 84 uint8_t controldata; > 85 int ret; > 86 > 87 if (!msg) > 88 return -ENOMEM; > 89 > >>> CID 163920: (TAINTED_SCALAR) > >>> Calling function "read" taints argument "msg->data". > 90 ret = read(bfd->fd, msg->data, UNIXSOCKET_ALLOC_SIZE - 16); What this seems to complain about is that we're writing arbitrary data to msg->data, and in lapd_receive() pass this to a LOGP that prints a hexdump of it. In osmo_hexdump, we of course do hex_chars[buf[i] >> 4] which we know to always work out to one of '0'..'f' for *any* data. This point seems to be missed by covertiy scan and it believes we may end up with an invalid index to hex_chars[]. So this is a false positive. Marked it as such. > *** CID 163919: Security best practices violations (STRING_OVERFLOW) > /source-Osmocom/libosmo-abis/src/input/unixsocket.c: 236 in unixsocket_line_update() > 230 struct unixsocket_line *config; > 231 char sock_path[PATH_MAX]; > 232 int ret = 0; > 233 int i; > 234 > 235 if (line->sock_path) > >>> CID 163919: Security best practices violations (STRING_OVERFLOW) > >>> Note: This defect has an elevated risk because the source argument is a parameter of the current function. > 236 strcpy(sock_path, line->sock_path); Please always use osmo_strlcpy(), here with sizeof(sock_path). > 237 else > 238 sprintf(sock_path, "%s%d", UNIXSOCKET_SOCK_PATH_DEFAULT, > 239 line->num); > 240 > 241 LOGP(DLINP, LOGL_NOTICE, "line update (line=%p)\n", line); > > ** CID 163918: Memory - illegal accesses (BUFFER_SIZE_WARNING) > /source-Osmocom/openbsc/openbsc/src/libbsc/bsc_subscriber.c: 83 in bsc_subscr_set_imsi() > > The next one is from me, in 6d804b1a7e375213cb4b3e437c2b9b8c68872164 "add struct bsc_subscr, separating libbsc from gsm_subscriber": > ________________________________________________________________________________________________________ > *** CID 163918: Memory - illegal accesses (BUFFER_SIZE_WARNING) > /source-Osmocom/openbsc/openbsc/src/libbsc/bsc_subscriber.c: 83 in bsc_subscr_set_imsi() > 77 } > 78 > 79 void bsc_subscr_set_imsi(struct bsc_subscr *bsub, const char *imsi) > 80 { > 81 if (!bsub) > 82 return; > >>> CID 163918: Memory - illegal accesses (BUFFER_SIZE_WARNING) > >>> Calling strncpy with a maximum size argument of 16 bytes on destination array "bsub->imsi" of size 16 bytes might leave the destination string unterminated. > 83 strncpy(bsub->imsi, imsi, sizeof(bsub->imsi)); Again, I should use osmo_strlcpy(), which correctly handles sizeof(buf), other than strncpy which might leave the string unterminated. ~N

1 0

libosmocore build failure cascade
by Neels Hofmeyr 08 Mar '17

08 Mar '17

As you may have noticed, Vadim's new coding generation code caused numerous builds to fall on their faces. The reasons why what failed are not so trivial, so let me explain. In short, - we place generated artifacts in the $builddir, which ensures clean builds after removing the $builddir. Because we do that, we sometimes need to also -I$(builddir)/include for builds where $(builddir) != $(srcdir). - for generated files, it is important to have proper make dependencies to rebuild them when the sources for generation change. - in build jobs, it is important to wipe the workspace clean, particularly in the presence of generated source files that don't have proper make dependencies. What I saw today: (1) libosmocore master build failed https://jenkins.osmocom.org/jenkins/job/libosmocore/866/ (2) gerrit libosmocore patch checking build *succeeded* for the failing patch (3) libosmocore build actually first *succeeded* even in clean src dir (4) libosmocore build from different dir on clean *system* failed (5) new generated files ended up in $srcdir (6) debian build complained about files present but not installed My first guess was: the gerrit job fails to clean the workspace and hence works because old headers remain; the master build fails because it properly cleans up the workspace and checks building from another dir. Not at all :) (1) In fact the libosmocore *master* build failed because it did not properly clean up the workspace. The old headers remained, but lacked some symbols that were now undefined during compilation. --> added rm -rf *; git checkout . to the libosmocore master build. --> https://gerrit.osmocom.org/2002 ensures regeneration by changed gen code (If there are more deps that could be added there, please go ahead!) (2) The gerrit libosmocore patch succeeded because it properly cleans up the workspace, and does not check building from a separate dir. So it regenerated all headers in $srcdir, which is fine when also building in $srcdir. --> https://gerrit.osmocom.org/1998 tests separate dir in jenkins.sh (3) If I still have libosmocore headers in e.g. /usr/local/include, the build will take those when missing in the src tree and may actually succeed. So I had to go and rm -rf /usr/local/include/osmocom to reproduce the failure. :/ (4) Build from different dir fails because coding/gsm0503_interleaving.c #includes a header that is generated in $builddir (already before this patch), but coding/Makefile.am did not -I$(builddir)/include. --> https://gerrit.osmocom.org/2003 adds -I builddir in coding/ (5) While generating files in $srcdir does not necessarily break builds, it's better to write to $builddir instead -- removing $builddir then clears the build state completely. Fixed up to generate to $builddir, also in: --> https://gerrit.osmocom.org/1996 generates gsm0503 to builddir (6) *All* files part of 'make install' need to be mentioned in debian/*, either as files to be ignored or files to be installed. Max fixed it in: --> https://gerrit.osmocom.org/1989 --> do we want to add deb build checking to the gerrit job? I spent some time on cleaning failures from that patch, but then spent some extra time to help us not run into these problems again... Thanks for being aware of these issues. ~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 1

osmo-sip-connector in bad state
by OMAR RAMADAN 08 Mar '17

08 Mar '17

If the SIP server dies in the middle of a call, osmo-sip-connector is in a bad state and generates a never ending stream of error messages: 58): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f25 It looks like the messages are generated from sofia-sip and I have managed to suppress the messages by setting the environment variable SU_DEBUG < 3: http://sofia-sip.sourcearchive.com/documentation/1.12.7/tport__internal_8h_… However, it looks like osmo-sip-connector is clearly in a bad state when this happens and we need a way to detect and release these ghosted calls.

4 15

packages broken by osmo-pcu commit "BTS: Convert relative frame numbers to absolute frame numbers"
by Neels Hofmeyr 07 Mar '17

07 Mar '17

Hi, the line if (abs(rfn - m_cur_rfn) > RFN_THRESHOLD) { in your recent osmo-pcu patch breaks the package builds (on ubuntu 16.10 x86_64 as well as i586). 1275a3f91a744e011b0dba82b09124d249c7abb5 / I74f00c11e5739d49f370ce6c357149e81d9aa759 I guess you should cast the uint32_t to e.g. long int explicitly to avoid the overloading ambiguity. abs((long int)(...)) It puzzles me why our gerrit build job did not run into this ambiguity though. My own build on my laptop doesn't even print a warning for this line. https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o… [ 110s] bts.cpp: In member function 'uint32_t BTS::rfn_to_fn(uint32_t)': [ 110s] bts.cpp:553:25: error: call of overloaded 'abs(uint32_t)' is ambiguous [ 110s] if (abs(rfn - m_cur_rfn) > RFN_THRESHOLD) { [ 110s] ^ [ 110s] In file included from /usr/include/c++/6/cstdlib:75:0, [ 110s] from /usr/include/c++/6/stdlib.h:36, [ 110s] from /usr/include/osmocom/core/linuxrbtree.h:97, [ 110s] from /usr/include/osmocom/core/timer.h:35, [ 110s] from ./bts.h:29, [ 110s] from bts.cpp:21: [ 110s] /usr/include/stdlib.h:735:12: note: candidate: int abs(int) [ 110s] extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur; [ 110s] ^~~ [ 110s] In file included from /usr/include/c++/6/stdlib.h:36:0, [ 110s] from /usr/include/osmocom/core/linuxrbtree.h:97, [ 110s] from /usr/include/osmocom/core/timer.h:35, [ 110s] from ./bts.h:29, [ 110s] from bts.cpp:21: [ 110s] /usr/include/c++/6/cstdlib:185:3: note: candidate: __int128 std::abs(__int128) [ 110s] abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; } [ 110s] ^~~ [ 110s] /usr/include/c++/6/cstdlib:180:3: note: candidate: long long int std::abs(long long int) [ 110s] abs(long long __x) { return __builtin_llabs (__x); } [ 110s] ^~~ [ 110s] /usr/include/c++/6/cstdlib:172:3: note: candidate: long int std::abs(long int) [ 110s] abs(long __i) { return __builtin_labs(__i); } [ 110s] ^~~ ~N

1 0

RFC: jenkins pipeline
by Max 05 Mar '17

05 Mar '17

Hi. Right now we have rather sophisticated CI/CD setup which is spread over several services (OBS for nightly packages, jenkins for CI) and repositories. It works well, but if I've got to somehow extend/alter it than I have to look in at least 3 different places: - ocmo-ci repo for common scripts - jenkins job in jenkins web ui - project's jenkins*.sh scripts I think it's not meant to be that way, it's just what has grown organically over the years. Right now we use recent enough jenkins which support Pipelines [1] plugin. The basic idea behind it is that each project has Jenkinsfile [2] in the repository which is self-contained configuration for CI. In theory enabling this plugin should not affect existing jobs as it's entirely separate job type. I suggest following: - enable Pipelines plugin in jenkins - configure new pipelines-based job pointing to non-master branch which we can use as a playground - once we comfortable with it - migrate existing CI (and possibly CD) to pipelines (as time permit) - switch gerrit from old jobs to new pipelines What do you think? Details are available via links below but here are some quick takeaways which motivated me to write this email: - we'll have actual CI job description under version control (right now it just sits in web ui) - we'll have single place to look for CI-related things (ok, maybe 2 places if we still need common library) - it's more eye-candy (it's clear which build step we're in and how long each step took) - it's easier to parallelize (e. g. run sanitizer and regular builds in parallel) On a related note: in general, who's point of contact for things like "please update jenkins plugin X to version Y"? [1] https://jenkins.io/doc/book/pipeline/ [2] https://jenkins.io/doc/book/pipeline/jenkinsfile/ -- 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

4 5

Osmocom nightly packages
by Martin Hauke 04 Mar '17

04 Mar '17

Hi, i'm building osmocom-related packages for openSUSE since a few years on OBS. https://build.opensuse.org/project/show/home:mnhauke:osmocom https://build.opensuse.org/project/show/home:mnhauke:osmocom-iuh Now i'd like to add support for RPM-based distributions to the osmocom-nightly packages. My current plan is to first add support for (open)SUSE based distributions and if there's interest then find out all the subtle changes that are needed for the spec-file to also add support for Redhat/Fedora/CentOS. # Phase1 - openSUSE_Leap_42.2 (x86_64) - openSUSE_Tumbleweed (i586, x86_64) - openSUSE_Factory_ARM (armv7l, aarch64) - SLE_12_SP2 (x86_64) # Phase2 - CentOS_7 (x86_64) - Fedora_25 (i586, x86_64) - RHEL_7 (x86_64) How does the current workflow for the daily check-in of the nightly debian/ubuntu packages look like? There's probably a bunch of scripts that do - git checkout from all relevant repositories - update changelog based on git commit messages - change the package version - create the new tarball - maybe osc local build - upload the tarball and the dsc to OBS - monitor if all the OBS-packages are successfully built and in state published Thanks in advance, Martin

2 1

osmo-(bts-)trx multi-trx is broken
by Max 04 Mar '17

04 Mar '17

Hi. There's been few updates to osmo-bts-trx recently so I've decided to get back to https://projects.osmocom.org/issues/1648 and it seems like it's completely broken: - the "multiplexing" option (osmo-trx -m -c 2) which used to work now leads to startup error of osmo-trx - the "separate channel" option (osmo-trx -c 2) which wasn't working properly but at least phone could see the network, now leads to situation where no network is visible Am I missing some magic combination of .cfg and command-line parameters which could make it work? Am I using too old version of uhd or smth else? The hw has not changed (usrp b210 + external 10MHz reference clock) but maybe I've got to do some calibrations on it? Any ideas as to what could be causing those regressions? Is there anyone out there for whom some multi-trx setup is working? If so, I'd like to compare notes to understand why it isn't working form me. -- 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

4 4

Virtual layer 1 - Questions
by Sebastian Stumpf 04 Mar '17

04 Mar '17

Hi, The virtual layer 1 is currently in a state where the l23 app can successfully connect to the bts and most of the signaling messages will be forwarded and handled. TCH is not yet implemented. I have some problems still, not knowing if these are caused by configuration problems or my coding :). - Trying to initiate a call via the mobile vty will result in VTY: call 1 123 OsmocomBB# % (MS 1) % Call has been rejected call 1 123 OsmocomBB# % (MS 1) % Call has been released And no actual call setup message is transfered over the Um interface. What could be reasons for that? I am using the test-sim option the mobile app offers. - Occasionaly the T3210 timer is fired, which causes a new registering within the network. LOG: gsm48_mm.c:336 timer T3210 (loc. upd. timeout) has fired How can i prevent that? - I did not implement a tdma or multiframe scheduler in the mobile uplink as the logical channel is directly put to the gsmtap-header and thus known by the bts. As Harald used a multiframe based scheduling for the bts downlink, i wonder if this might be necessary, though. To submit msgs with the correct frame number for example. - In my wireshark capture files, the gsmtap messages sent over the multicast sockets are only recognized as UDP messages. I have to "cast" them with the wireshark context menu "Decode as...". Why? I would be super happy if someone of you could check out my project (osmo-bts, branch stumpf/virt-phy + osmocom-bb, branch stumpf/virt-phy) try to run it with the config files lying within the project folders and tell me the problems they see :). Here you can find a wireshark capture file of 2 mobiles connecting to a virt bts. I also tried to init calls from both of them but the call setup is not send. https://www.dropbox.com/s/2ccky4ljc8ngahz/mobilex2--ms-virt--bts-virt--bsc-… Kind Regards, Sebastian Stumpf

2 7

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC March 2017