OpenBSC June 2017

openbsc@lists.osmocom.org

23 participants
42 discussions

by Max

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

8 years, 3 months

access grant channel on osmo(-bts)-trx

by Max

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

8 years, 3 months

Error encountered using osmo-trx=0.1.9.20170621

by Ron

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>

8 years, 3 months

jenkins plugin question

by Max

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

8 years, 3 months

osmo-bts revert: osmo-bts-trx regression detected by osmo-gsm-tester

by Neels Hofmeyr

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

8 years, 3 months

AddressSanitizer in FreeBSD jenkins builds

by Pau Espin Pedrol

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

8 years, 3 months

heads up: no more \brief in libosmocore

by Neels Hofmeyr

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

8 years, 3 months

SCCP/M3UA: PC and routing questions

by Neels Hofmeyr

Trying to get the HNBGW to communicate with the MSC. I receive Iuh from the femto cell as usual, send to the MSC, and end up in an infinite loop where osmo-stp and osmo-hnbgw send the same message back and forth to each other. osmo-hnbgw's local IuCS PC is 23, the MSC is PC 1. It seems when osmo-hnbgw receives a message to PC 23, i.e. to itself, it thinks that its own PC isn't local, finds its own as-clnt-CS in the table of routes, and feeds it to m3ua_tx_xua_as(). osmo-stp then sends it back. repeat. It seems overkill that a "client" like osmo-hnbgw should be capable of routing in the first place. It could switch off routing entirely and receive & handle every message it receives itself. But assuming that this were nonsense: IIUC it should rather decide that its own PC 23 is local, in: bool osmo_ss7_pc_is_local(struct osmo_ss7_instance *inst, uint32_t pc) { OSMO_ASSERT(ss7_initialized); if (pc == inst->cfg.primary_pc) return true; /* FIXME: Secondary and Capability Point Codes */ return false; } Apparently this global primary_pc is set in osmo_sccp_simple_client(). Since in the osmo-hnbgw I'm (so far) creating two simple clients with distinct PCs (IuCS is 23, IuPS is 24), the primary_pc is overwritten with 24. After that we always fail to notice 23 as a local PC and bounce messages for self right back down the SCCP stack, because apparently we find a route for 23 instead. A "matching" route is recognised by osmo_ss7_route_find_dpc(): if ((dpc & rt->cfg.mask) == rt->cfg.pc) My own local client gets entered as route, with rt->cfg.mask == 0 and rt->cfg.pc == 0, so an arbitrary dpc & 0 == 0, matches always. It seems awfully easy to create a fatal infinite loop flooding the network and CPU -- simply send a message to a DPC neither side sees as local. Anyway... Which way to go to serve more than one PC in a program? It appears that either an osmo_sccp_simple_client() call's local PC or an osmo_sccp_user_bind_pc()'s PC should be stored&found as a local PC. ... or both. Is the "right" way to have two PCs: having two osmo_sccp_simple_client()s with an sccp_user each; or rather one osmo_sccp_simple_client with two users? Or, should we for the OsmoHNBGW just have one osmo_sccp_simple_client() and one user, i.e. only one PC to receive both IuCS and IuPS messages? All we do is feed both of them out to Iuh anyway... (This seems an easy way out of the multi PC problem, but our MSC wants to serve one PC for BSSAP=2G and one PC for RANAP=3G, so we will need to solve the multi-PC problem anyway.) There are many directions I could head to, is any one better than the others? Thanks! ~N

8 years, 3 months

osmo_sock_get_name() order

by Neels Hofmeyr

In january, osmo_sock_get_name() was introduced and prints the connection info for a given fd, which looks like this: 127.0.0.1:2905<->127.0.0.1:60661 However, when I first saw this in a log, I was confused: I expect the local address and port to be on the left, while in this string it is on the right. Is it only me and I should get used to it, or can we reverse that so the local part is on the left? I could argue that in most GSM graphics and ladder diagrams, the client side is on the left, and that we would typically use this string on the client side to indicate where we connected to. Is this even true? Should there be an arg to pick the preferred order? :P I'll submit a patch if anyone agrees. ~N

8 years, 3 months

knowing connected subscribers

by robert

Hello, Is there a way in openBSC to know if a certain phone that previously connected to my BTS is still connected at a given time ?

8 years, 3 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2017