OpenBSC

openbsc@lists.osmocom.org

11 participants
4278 discussions

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

SCCP/M3UA: PC and routing questions
by Neels Hofmeyr 22 Jun '17

22 Jun '17

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

2 4

osmo_sock_get_name() order
by Neels Hofmeyr 22 Jun '17

22 Jun '17

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

3 4

knowing connected subscribers
by robert 21 Jun '17

21 Jun '17

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 ?

3 4

jenkins and osmo-ci
by Max 21 Jun '17

21 Jun '17

Hi. I've problem figuring out how to use osmo-ci in jenkins: the build steps for osmo-bts-gerrit and osmo-pcu-gerrit look pretty-much the same but osmo-pcu fails with: osmo-layer1-headers.sh: command not found while osmo-bts (which uses other scripts from osmo-ci) works fine. Any ideas where this difference might come from? -- 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 5

how to use the CTRL interface to set TRAPs.
by emily mcmilin 20 Jun '17

20 Jun '17

Hi all, I have some uncertainty about how to use the CTRL interface to set TRAPs. In the OsmoBSC user manual (for example), the example provided doesn't specify an option to set for the 'var' I might be particularly interested in monitoring: `$ ./bsc_control.py -d localhost -m` Is this the default to monitor all? Can I go about narrowing this? Also, I don't feel like I quite understand the TRAP portion of "Table 2: Variables available over control interface" in the OsmoBSC user manual: For example, the 'name' column seems to generally indicate the 'var' that one would pass in a GET/SET command, so I'm assuming the 'name' associated with the TRAP-enabled rows has the same significance. But these 'names' have no real meaning to me in terms of my experience with VTY, for example 'notification'. I have tried to look toward the osmo-nitb unit tests for inspiration, as there is fantastic coverage for GET/SET, out haven't seen similar for TRAP. Can someone please point me in the right direction? Thanks, Emily

3 9

jenkins: Osmocom_Sanitizer build fails
by Neels Hofmeyr 20 Jun '17

20 Jun '17

Today I noticed that the Osmocom_Sanitizer build has been broken for a long time, failing at libosmocore/src/viterbi_sse.c. But that seems like the fault of the way the Osmocom_Sanitizer builds: When I build libosmocore with --enable-sanitize, everything works out. When I instead build with `make CFLAGS+="..."', some CFLAGS are dropped and the build fails. The working commandline is: ./configure --enable-sanitize make V=1 [...] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -fsanitize=address -fsanitize=undefined -Wall -g -O2 -fsanitize=address -fsanitize=undefined -msse3 -msse4.1 -MT viterbi_sse.lo -MD -MP -MF .deps/viterbi_sse.Tpo -c viterbi_sse.c -fPIC -DPIC -o .libs/viterbi_sse.o The failing one is: ./configure make CFLAGS+="-fsanitize=address -fsanitize=undefined" V=1 [...] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -fsanitize=address -fsanitize=undefined -Wall -fsanitize=address -fsanitize=undefined -MT viterbi_sse.lo -MD -MP -MF .deps/viterbi_sse.Tpo -c viterbi_sse.c -fPIC -DPIC -o .libs/viterbi_sse.o i.e. in the failing build, these cmdline args are missing: -O2 -g -msse3 -msse4.1 So it seems that the CFLAGS+="stuff" is not working as intended. The alternative is to build with the ./configure --enable-sanitize, which I added at some point. But not all libs have this switch, AFAIR. I have added the --enable-sanitize configure option to libosmocore, and asked others to follow up in other repositories in the same fashion. I think this hasn't worked out everywhere yet. Does it make sense to refresh the sanitize build effort?: switch the Osmocom_Sanitizer build to using this configure flag and add it where it is missing. But I guess we should instead add the sanitize switch to each individual build script for the various *osmo* build jobs and switch off the Osmocom_Sanitizer build instead. I repeat myself, but adding --enable-sanitize is not a lot of effort. See http://git.osmocom.org/libosmocore/commit/?id=a23817622b28cb1969a73ffd36da5… I created https://osmocom.org/issues/2330 ~N

3 5

core/conv: further Viterbi decoder optimizations
by Vadim Yanitskiy 19 Jun '17

19 Jun '17

Dear all, I would like to know your opinions about some optimizations of Viterbi decoder, which were already discussed previously. First of all, I would like to share some benchmarking results. I used the test cases ("osmo-conv-test"), written by Tom Tsou, to ensure that SIMD optimization is integrated correctly. And, shortly speaking, the results are almost equal. Older version of decoder is a little bit faster, but I think it's because one is being compiled with "-march=native". Returning back to the subject, as we allocate and free some memory on every osmo_conv_decode_acc() call, what may happen very frequently and tear down performance on some hardware, there was the following suggestions: 1) Use static memory allocation where it's possible. 2) Use talloc for dynamic allocation. 3) Internal caching: Fri May 9 18:23:03 UTC 2014, Tom Tsou wrote: > Internal caching was in the original implementation, but > stripped from the submitted version mainly for simplicity > and avoiding the need for global variables, though we seem > to be having that discussion anyway ;-) The trellis values > can be cached based on pointer or hashed code. That works well > until threading is involved and cache access needs to be locked. > Those are features I need, but can probably be ignored in this > case. > > Again, I think the API should be kept intact. Internal caching, > can be a topic for later discussion. So, I am open for your ideas, opinions and remarks. With best regards, Vadim Yanitskiy.

4 6

aoip branch in openbsc.git
by Neels Hofmeyr 18 Jun '17

18 Jun '17

Hi Philipp, I have rebased the 'aoip' branch onto openbsc master. A test by the osmo-gsm-tester of this state was successful. Pending is to also verify voice and all of 3G still works there (will then update vlr_2G and vlr_3G branches). Some commits have been amended to, a) adjust libsmpp changes to use vlr_subscr, b) fix the msc_vlr unit tests after your rename of a_tx() and a_page() (don't really know why I didn't hit that earlier). c) add one comment So beware, if you rebase your most recent patches onto the 'aoip' branch, git may want to apply a few patches again because they slightly differ, even though their commit logs are identical. You need to sanity-check with 'rebase -i'. ~N

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC