OpenBSC June 2017

openbsc@lists.osmocom.org

23 participants
45 discussions

SS7 / SCCP design question: one or several SCCP instances?
by Neels Hofmeyr 29 Jun '17

29 Jun '17

We need to decide which way to go with point codes, sccp- and ss7-instances. pmaier and I have reached different conclusions and wrote patches going in opposite directions, now we need to decide and cosolidate: The MSC has various connections over SCCP: it serves BSSAP for several BSCs, and RANAP for several HNBGWs. BSC - A MSC: BSC -}----------> BSSAP BSC - -----> RANAP / HNBGW -}-/ IuCS HNBGW - 1) I went for exactly one point code at the MSC (say PC=1). There is exactly one osmo_ss7_instance and one osmo_sccp_instance. The MSC has separate sccp_user_bind()s for the BSSAP and the RANAP SSNs. So PC=1,SSN=BSSAP goes to the A-interface sap_up(), and PC=1,SSN=RANAP goes to the IuCS sap_up(). When comparing to the TCP/IP model, the paradigm here is that a PC is like an IP address and the SSN like a port number. At the server, the MSC, I have one PC (IP address) and listen on one SSN (port) per protocol served, and clients all connect to the same PC+SSN, receiving separate connection IDs. I can also use the calling address to know which client I'm talking to. Hence I moved the osmo_sccp_instance creation up to "the top" and created two sccp_user_bind()s, one for BSSAP and one for RANAP. This works in practice. I can tear down and set up individual sccp_users (i.e. disable/enable IuCS or A separately), and handling different clients is done by the conn_ids and possibly keeping distinct osmo_sccp_addresses. An pseudocode MSC VTY config for this scenario could look something like this: msc sccp local-pc 0.0.1 ssn-iucs $OSMO_SSN_RANAP ! -> to IuCS rx cb ssn-a $OSMO_SSN_BSSAP ! -> to A rx cb remote-bsc 1 pc 1.0.1 remote-bsc 2 pc 1.0.2 remote-hnbgw 1 pc 2.0.2 i.e. one local PC is configured, each protocol has its separate SSN, each sccp_user_bind() serves all clients for that SSN. This is the direction I took to add IuCS to AoIP. 2) pmaier added VTY configuration for various point codes, and went the other way: the MSC creates a separate osmo_sccp_instance per BSC connection. (The MSC is told the addresses of all known BSCs and) every time a BSC is configured via VTY, a new osmo_sccp_simple_client() is created. IIUC the MSC then has a distinct local PC for each BSC, and for each HNBGW. In this model there still is a code problem I noticed while adding IuCS to AoIP in OsmoMSC: if I call osmo_sccp_simple_client() a second time with a different PC, the osmo_ss7_instance used is still the same (still id=1), and notes this second PC as its global local PC. The messages received for the first client's PC are then seen as remote and routed back out -> infinite message loop. A solution here would be to either a) use a separate osmo_ss7_instance per osmo_sccp_simpe_client() (simply add an ss7 instance id parameter to osmo_sccp_simpe_client() and increment by one each time) or b) implement the routing algorithm so that it notices the local PCs of several local SCCP clients. A VTY config for this scenario so far looks like this: ! define some addresses, referenced below cs7 instance 1 sccp-address msc_local subsystem-number 254 point-code 0.0.1 routing-indicator PC sccp-address bsc_remote subsystem-number 254 point-code 0.0.2 routing-indicator PC sccp-address bsc_remote2 subsystem-number 254 point-code 0.0.3 routing-indicator PC msc bsc cs7-instance 1 calling-addr msc_local called-addr bsc_remote bsc cs7-instance 1 calling-addr msc_local called-addr bsc_remote2 (I'm not sure whether it is possible to have several sccp_instances with the same msc_local address, but we would find solutions for these petty issues once we've decided which way to go.) (I also think 'calling-addr' and 'called-addr' should rather be named 'local-addr' and 'remote-addr': depending on who calls who, the calling-addr can be the remote or the local one. That's also besides the point for now.) My personal idea is that 1) is simpler: we have one ss7 instance per program, no matter how many clients are served. I can still tear down and set up individual sccp_users (i.e. disable/enable IuCS or A separately), and handling different clients per SSN is done by the conn_ids and possibly keeping distinct osmo_sccp_addresses of the clients. 2) seems to me easier to misconfigure and it sounds to me like a paradigm of creating a whole new server for each client that connects, so instead of using an ss7_instance's routing, we create separate instances, each sending to only one counterpart. But is 2) maybe the correct way to go for reasons I'm not aware of? I notice that what I wrote is biased towards 1) because that's my POV, but this is indended to be a neutral question. We need a choice for 1) or 2) so that pmaier and I can adjust and merge our patches accordingly. Can you help us decide, hopefully with some background knowledge on how an SCCP network is intended to be set up? Thanks! ~N

3 5

aoip branch
by Neels Hofmeyr 28 Jun '17

28 Jun '17

I successfully tested some new patches on the AoIP branch locally and pushed them to the openbsc.git/aoip branch. They allow using 3G with AoIP. @pespin: if aoip tester runs fail now, that's probably the cause. @pmaier: I tried to apply all patches found on the pmaier/aoip branch, but excluded the commits started with "MSC side reset" because of build failure. The failure is the same I saw a few days ago, still unchanged: CCLD osmo-bsc_nat ../../src/libcommon/libcommon.a(common_vty.o): In function `bsc_vty_go_parent': /n/s/osmo/git/openbsc/openbsc/build-3G/src/libcommon/../../../src/libcommon/common_vty.c:130: undefined reference to `osmo_ss7_vty_go_parent' ../../src/libcommon/libcommon.a(common_vty.o): In function `bsc_vty_is_config_node': /n/s/osmo/git/openbsc/openbsc/build-3G/src/libcommon/../../../src/libcommon/common_vty.c:140: undefined reference to `osmo_ss7_is_config_node' collect2: error: ld returned 1 exit status I suspect you still have some of your work not pushed to libosmo-sccp? I can't find a private branch or patches on gerrit about osmo_ss7_vty. In general I think it would be good to always keep your work on a private branch and push it frequently (doing anything you like on it, amending and so forth). For collaboration, but also to have a backup of your patches...? If you like, we can have a call soon to figure out a rebase of your work onto aoip. A merge conflict is solved on the neels/pmaier_aoip branch ('git fetch' first), but I get above build failure. ~N

3 3

.deb build as jenkins test
by Max 27 Jun '17

27 Jun '17

Hi. In a light of https://projects.osmocom.org/issues/2340 I'd like to add .deb build as an additional step for jenkins jobs triggered by gerrit push. It'll mean longer build times but it'll prevent breaking changes from reaching master. It won't guarantee that we won't see occasional arch/version specific breakage in https://build.opensuse.org/project/monitor/network:osmocom:nightly but it should make nightly builds more stable and easier to maintain. What do you think? -- 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

2 1

osmo-trx -m is broken
by Max 26 Jun '17

26 Jun '17

Hi. I've got following error in latest osmo-trx: ./Transceiver52M/osmo-trx -x -c 2 -m -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting master clock rate selection to 'automatic'. ALERT 139666585152384 10:32:48.8 UHDDevice.cpp:642:open: Channel setting failed - map::at ALERT 139666585152384 10:32:48.8 UHDDevice.cpp:642:open: Channel setting failed - map::at ALERT 139666585152384 10:32:48.8 osmo-trx.cpp:454:main: Failed to create radio device ALERT 139666585152384 10:32:48.8 osmo-trx.cpp:454:main: Failed to create radio device Shutting down transceiver... If I remove -m than it starts as expected. -- 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 3

access grant channel on osmo(-bts)-trx
by Max 26 Jun '17

26 Jun '17

Hi. The number of blocks reserved for access grant channel is determined by BS-AG-BLKS-RES sent by BSC in SI3: see 3GPP TS 44.018 Table 10.5.2.11.1. In case of sysmobts and lc15 it's used as lch_par->agch.u8NbrOfAgch. Unfortunately, I'm unable to find appropriate counterpart for scheduler.c/osmo-bts-trx. Any ideas as to how can we apply BS-AG-BLKS-RES to osmo-bts-trx (and, of course test that the proper setting was indeed applied) would be appreciated. -- 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

Error encountered using osmo-trx=0.1.9.20170621
by Ron 25 Jun '17

25 Jun '17

Hi All, We encountered an error upon running the "osmo-trx” using Ubuntu 16.04 OS. We have an existing "osmo-trx” in one of our server and running just fine. Upon checking for the version, the working “osmo-trx” is running at “0.1.9.20170530”, while the new one with an error is running at “0.1.9.20170621”. Kindly see below error for your reference: # osmo-trx osmo-trx: symbol lookup error: osmo-trx: undefined symbol: _ZN3uhd4usrp10multi_usrp9ALL_GAINSE Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

2 2

jenkins plugin question
by Max 23 Jun '17

23 Jun '17

Hi. I've got add few more parameters to OsmoBTS and OsmoPCU gerrit jobs in jenkins. So far this has been done by manually adding parameter axis and writing combination filter for axis parameters. It's error prone and rather ugly. Much better way would be to use JobDSL and declare entire job programmatically but until that happens there's nice intermediate solution: https://plugins.jenkins.io/matrix-combinations-parameter I'd like to install this plugin onto our jenkins and convert above mentioned jobs to use it. Opinions, other ideas? On a related note: who's responsible for jenkins config/update? Shall I just contact that person directly if I need some plugin in jenkins, or shall I ask in ML? -- 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 2

osmo-bts revert: osmo-bts-trx regression detected by osmo-gsm-tester
by Neels Hofmeyr 23 Jun '17

23 Jun '17

Today we faced consistent osmo-bts-trx failures and I submitted a revert of commit "RSL: receive and send multiple SI2q messages". See https://osmocom.org/issues/2338. Why did we not catch it earlier? There was a bug in the osmo-gsm-tester build where the build could get stuck on a local branch instead of building newly pulled changes. That was fixed about a day ago, so we saw the breakage today. ~N

1 0

AddressSanitizer in FreeBSD jenkins builds
by Pau Espin Pedrol 23 Jun '17

23 Jun '17

Hi, Some of you may have noticed that I have been lately fixing compilation warnings + enabling -Wall and -Werror on jenkins build for several osmocom libraries. While doing so, I noticed that the following lines trying to enable AddressSanitizer support are actually failing when building with the FreeBSD jenkins slave, probably due to it using some other shell without bash support: ./configure: CFLAGS+= -fsanitize=address -fsanitize=undefined: not found ./configure: CPPFLAGS+= -fsanitize=address -fsanitize=undefined: not found The source lines are: CFLAGS+=" -fsanitize=address -fsanitize=undefined" CPPFLAGS+=" -fsanitize=address -fsanitize=undefined" After changing them to support sh and submitting the change in gerrit [1], AddressSanitizer was enabled in FreeBSD for first time, but I started getting lots of link issues with AdressSanitizer (asan) related symbols. I read in several places that there seems to be a known issue with FreeBSD 10.3 and clang-3.4.1 (what we are using) regarding use of AddressSanitizer [2, 3]. I then tried configuring CC in the jenkins slave to use clang37 instead of cc (clang-3.4.1), and then the linking issue seems to be solved, but again a new compiler bug related to usage of __builtin_cpu_supports shows up, preventing compilation of libosmocore [4]. I think the best solution is to disable explicitly AddressSanitizer in contrib/jenkins.sh when running from FreeBSD, so the behaviour is actually the same as before, in which it was implicitly not enabled due to a syntax error. Once we move to FreeBSD11 and clang-3.8 we can try enabling it again. If nobody comes with a better solution or is against this, I will proceed to do so during next hours/days. [1] https://gerrit.osmocom.org/#/c/3024/2/configure.ac [2] https://stackoverflow.com/questions/30085036/linking-clang-address-sanitize… [3] https://webcache.googleusercontent.com/search?q=cache:CZmrK35zigEJ:ea5faa5p… [4] https://bugs.llvm.org//show_bug.cgi?id=25510 -- - Pau Espin Pedrol <pespin(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

heads up: no more \brief in libosmocore
by Neels Hofmeyr 23 Jun '17

23 Jun '17

I've just merged a patch that enables the AUTOBRIEF function of doxygen, in libosmocore. Every API doc's first sentence up to the first full-stop '.' is now automatically its \brief description. You may omit the \brief. This is so far only in libosmocore, since I'm not aware of us generating doxygen in any other repositories. Either way we can and should avoid the \brief, and in doubt enable the AUTOBRIEF everywhere. I've also shifted around the \file directives across libosmocore, and wrote a wiki page that describes it among other things: https://osmocom.org/projects/cellular-infrastructure/wiki/Guidelines_for_AP… Related: the series of "doxygen:" commits that just came into libosmocore master. http://git.osmocom.org/libosmocore/commit/?id=87e4550585c643e97e0003119b254… http://git.osmocom.org/libosmocore/commit/?id=17518fe393a37781c84d09836256b… Do any other code trees need this switching? ~N

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2017