OpenBSC March 2017

openbsc@lists.osmocom.org

22 participants
48 discussions

by OMAR RAMADAN

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.

8 years, 3 months

packages broken by osmo-pcu commit "BTS: Convert relative frame numbers to absolute frame numbers"

by Neels Hofmeyr

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

8 years, 3 months

RFC: jenkins pipeline

by Max

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

8 years, 3 months

Osmocom nightly packages

by Martin Hauke

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

8 years, 3 months

osmo-(bts-)trx multi-trx is broken

by Max

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

8 years, 3 months

Virtual layer 1 - Questions

by Sebastian Stumpf

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

8 years, 3 months

how to stop paging

by Neels Hofmeyr

I have a general question about the Paging procedure, specifically about how to stop paging. In libbsc, we have Paging management that receives a request to Page from the MSC and then repeatedly Pages the MS on all BTSes N times or until told to stop. In the NITB, we have code closely tied to the BSC and all BTS management, so that when we receive a Paging Response, we can right away stop sending Paging Commands on all BTSes. So can the standalone-BSC: it stops paging when it received a Paging Response. In OsmoMSC with Iu- and A-interfaces, that's not possible. Looking in 08.08, there seems to be no A-interface message that tells the BSCs "thank you, you can stop paging now". If one BSC or RNC has relayed back a Paging Response from one of the cells, the MSC has no way to tell the other base stations that it's fine to stop sending dozens of Pagings out for "minutes", which would be useless now anyway because the MS has called back via another base station already. Is that a fact of life? We continue Paging in all cells where the MS is not visible? Should the BSC/RNC part of the network page only once, so that "stop paging" is a no-op? Of course we first check which LAC the MS was first seen on and page only there. Is the idea to send paging to one cell, and that cell stops Paging by itself when it received a Paging Response that it relays to the MSC? But IIRC Paging is supposed to spread out across other base stations if at first it didn't succeed -- I recall to have read that in HNB-GW specs or somewhere close to that. Our OsmoHNBGW so far simply Pages everywhere. The practical reason I'm asking is that in the msc_vlr tests, I so far explicitly check whether the "stop paging" function was called. Now on the Iu branch, without libbsc, there is no such function. Should I drop those checks because we will never have that? Or should I add some shim function we call just for the tests so far, which will at some point tell the base stations that Paging has concluded? Thanks for any hints, ~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

8 years, 3 months

my patches prioritized

by Neels Hofmeyr

I currently have a whole series of patches on gerrit, many of which fail to build. Here are the pivotal ones I am waiting for, the other patches can be mostly ignored until these are through: https://gerrit.osmocom.org/1682 (struct bsc_subscr) Waiting for a comment. VLR and 3G branches build on it. I'm happy to change the patch, but not sure whether I really have to. IMHO there are benefits to this unusual way, but one word ("no") is enough. https://gerrit.osmocom.org/1923 (cosmetic prep for 1924) https://gerrit.osmocom.org/1924 (python tests: VTY connection speedup) These two are needed for the openbsc python tests speedup patches to work. https://gerrit.osmocom.org/1962 (explicitly terminate ctrl_type_vals[]) https://gerrit.osmocom.org/1940 (find unterminated value strings) The first is a fixup for the second to work, the second one is needed for all of the other value_string topic patches to work. I'd like to add this check to jenkins now, so that all incoming value_string[]s are validated. https://gerrit.osmocom.org/1906 (python tests from separate build dir) I usually build 2G and 3G separately, and I'd like to run the py tests in each dev cycle, now that they are faster. So I'd love to merge this. Hope this helps to save some time... ~N

8 years, 3 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC March 2017