OpenBSC September 2017

openbsc@lists.osmocom.org

26 participants
58 discussions

dynamic traffic channels
by Neels Hofmeyr 20 May '25

20 May '25

On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels

3 5

GAPK status update
by Vadim Yanitskiy 03 Dec '17

03 Dec '17

Dear Osmocom community, I have been working on GAPK (GSM Audio Packet Knife) for some time, and now I would like to share some achievements. Previously GAPK was represented as a single binary that could be called with some command line arguments in order to perform required operations. This is only handy for humans, but not for other programs, which may also need to perform some format / codec conversations or audio capture / playback. One of such programs is the mobile from OsmocomBB project. Currently, when you're making a voice call, both audio capture and playback are only possible on the L1 side, i.e. on a Calypso based phone. Of course, the audio stream can be redirected via MNCC socket, but this is not what a regular OsmocomBB user would like to do. Moreover, there is a lack of AMR codec support. Also, there is another GNURadio based project named GR-GSM. In short, this is a set of blocks for GSM signal reception, demodulation and further processing. At the moment, one has TCH Full Rate decoding capabilities only. Audio playback is not supported yet. Having these projects in my mind, I have got an idea of creating a shared library from the GAPK source code. And, a few days ago I was managed to get the audio playback working in OsmocomBB. I hope, this library will be also usable for other projects. Brief list of changes were made: - Composed a shared library named libosmogapk - All exposed symbols have got an 'osmo_gapk' prefix - Added a pkg-config manifest and a symbol export map - Integrated the Osmocom logging framework - Benchmarking is now disabled by default - Processing queue now based on the linuxlist - Fixed program exit due to ALSA buffer underrun - Fixed ALSA audio playback from file - Old gapk application was renamed to 'osmo-gapk' and linked against the library - Adjusted verbosity level (normal / debug) - Fixed I/O combinations (ALSA, RTP, file...) check All changes could be found at the fixeria/lib branch of GAPK. I hope to see them merged, and open for discussions ;) With best regards, Vadim Yanitskiy.

2 4

RFC: gerrit verifcations as Jenkins Job Builder YAML file
by André Boddenberg 30 Oct '17

30 Oct '17

Hi all, I've created a prototyp'ish JJB YAML file [1] that holds all current gerrit verification jobs on jenkins.osomocom.org. Holger and Lynxis suggested to explore this way of managing Jenkins jobs in the "jenkins build slaves: Rationale for some builds in docker vs. some not?" thread. Following differences occurred, while clicking through all gerrit jobs configurations: - some jobs using gcc c compiler warnings v3, some v4 - some jobs are verifying drafts, some not - only two gerrit jobs are allowing concurrent builds Are these differences wanted? All job differences are commented in the YAML file. The jobs are deployed on jenkins.blobb.me [2]. What do you think about this approach [1] in general? Regards, André [1] https://gerrit.osmocom.org/#/c/3911/1 [2] https://jenkins.blobb.me/view/gerrit-JJB/

4 4

RFC: Getting rid of FreeBSD build testing
by Harald Welte 29 Oct '17

29 Oct '17

Dear all, Holger and I (plus later the sysmocom team) had a discussion about whether we should continue to keep the FreeBSD build testing. Right now, jenkins is set up in a way to test build of a patch on Linux (currently Debian 8) and FreeBSD (currently 10.3). Only if it builds and passes "make check", the patch gets the magical "+V" so it can be merged. While in general it's of course good practise to write portable code and to test building on multiple operating systems, this adds quite a bit of extra effort: * patches every so often don't build on FreeBSD due to include header differences or the like, requiring extra iterations of a patch * the build takes longer time as the build matrix is multiplied by two operating systems * we cannot easily/safely migrate the way we buld to docker, as docker on FreeBSD is experimental Particularly during my recent OpenGGSN developments (IPv6) support, this was a big PITA and I'm sure I spent more time in debugging FreeBSD build issues than actually writing the code in the first place. Given that we arr not aware of anyone using the Osmocom stack on FreeBSD, the suggestion is thus to focus our available time on actual GSM related features rather than fixing up portability issues. So unless we receive significant complains as a response to this e-mail, we will disable the automatic build testing for patches on FreeBSD. This doesn't mean we will drop related code from our projects. We still appreciate build and other fixes for other platforms, but those would have to come as contributions from users on those platforms, rather than something that's actively maintained and tested by Osmocom upstream. If we want to extend build testing, I think it's more useful to have e.g. ARM/Linux builds, or clang builds on Linux than the FreeBSD builds. Let me know what you think. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 3

log level everything
by Keith 17 Oct '17

17 Oct '17

Hi Max! Since https://gerrit.osmocom.org/#/c/3148/ I am no longer able to individually control log levels in the vty. I used to use logging level all everything, then this allowed me to do such as logging level smpp fatal (get rid of annoying bind check every 30 secs) logging level [category i'm interested in] debug Now, all I seem to be able to do is turn all categories to a level with logging level all debug or logging level all notice. individual category directives such as logging level pag fatal make no difference. What am I missing? Thanks! BTW, I get the behaviour I need back by moving your check below the check for "all":: diff --git a/src/vty/logging_vty.c b/src/vty/logging_vty.c index 01480b1..fb2cab8 100644 --- a/src/vty/logging_vty.c +++ b/src/vty/logging_vty.c @@ -213,17 +213,18 @@ DEFUN(logging_level, return CMD_WARNING; } - if (strcmp(argv[1], "everything") == 0) { /* FIXME: remove this check once 'everything' is phased out */ - vty_out(vty, "%% Ignoring deprecated logging level %s%s", argv[1], VTY_NEWLINE); - return CMD_SUCCESS; - } - /* Check for special case where we want to set global log level */ if (!strcmp(argv[0], "all")) { log_set_log_level(tgt, level); return CMD_SUCCESS; } + if (strcmp(argv[1], "everything") == 0) { /* FIXME: remove this check once 'everything' is phased out */ + vty_out(vty, "%% Ignoring deprecated logging level %s%s", argv[1], VTY_NEWLINE); + return CMD_SUCCESS; + } + + if (category < 0) { vty_out(vty, "Invalid category `%s'%s", argv[0], VTY_NEWLINE); return CMD_WARNING;

5 13

osmo-bts-trx fails frequently on osmo-gsm-tester
by Neels Hofmeyr 10 Oct '17

10 Oct '17

We're still having massive stability problems with osmo-bts-trx on the osmo-gsm-tester. I have run a tcpdump on the ntp port for the past days, and nothing is doing ntp besides the actual ntp service. Today I started ntp while an osmo-bts-trx run was active and what do you know, the osmo-bts-trx process exits immediately. I think this is bad, osmo-bts-trx shouldn't use wall clock time for precise timing needs. Besides that, I have no idea what could cause the clock skews, except maybe that the CPU or the USB are not fast enough?? I'm wondering, is there still such a thing as a separate linux realtime kernel? We will soon take to productive use another main unit which will be a cleanly installed OS. If we see the same problems on that system and can't find a software fix, we may need to reconsider the tester for osmo-bts-trx... ~N

8 26

randomness of identifiers
by Harald Welte 05 Oct '17

05 Oct '17

Dear all, Max has been pushing https://gerrit.osmocom.org/#/c/1526 for quite some time, but there was still no conclusion in its review. I guess after more than 8 months in limbo, it's about time we decide how to move ahead with this. In general, we *want* secure/safe identifiers like TMSIs that are not easy to predict by an attacker. Using rand() or some other pseudo-random generator with a predictible seed like the time of the process start is probably not the best choice here. Using the rather strong entropy pool of /dev/urandom or getrandom() is apparently not a good choice either: We can exhaust the entropy pool at whch point we would have to block/wait, which we of course cannot in our architecture. So what do we do? I think we first have to differentiate on the type of randomness needed. Is it a random identifier like TMSI? Is it a random challenge used in cryptographic authentication? Is it random data used for a key? Those require different levels of randomness. For TMSI allocation, my "cryptographic gut feeling"[tm] is that something like rand() or any other pseudo-random generator of significantly large period is sufficient *if* it is seeded by a non-predictable value. So something like seeding with getrandom() result should be fine? For random challenges in authentiation I would probably go for direct use of urandom / getrandom(). If the entropy is exhausted, the quality of the random numbers will get lower, but getrandom() will always return up t 256 bytes. For long-term stable key (Ki/Op) generation for provisioning SIM cards + populating a HLR, I would certainly opt for using stronger randomness sources. However, I don't think we actually implement that anywhere, do we? What do you guys think? Is there somebody on this list more cryptographically qualified to give us proper guidance? If you know somebody skilled who might want to help but is not on this list, would you invite them to join this discussion? -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 7

osmo-bsc integration to osmo-msc
by Ron 04 Oct '17

04 Oct '17

Hi All, Is there a link on how to integration osmo-bsc to osmo-msc? or osmo-bsc_nat is required to integrate osmo-bsc to osmo-msc? A config file for both osmo-bsc and osmo-msc that can be shared will be greatly appreciated. TIA. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

3 11

branches in openbsc.git
by Neels Hofmeyr 02 Oct '17

02 Oct '17

another call for anyone aware of important branches on openbsc.git to please name them, so that they can be migrated to the new repositories. But foremost, please name them, thanks! ~N

4 7

Osmo_IuH_building_problems
by Popovic Goran 02 Oct '17

02 Oct '17

HI Neels, Thanks for provided answers and tips. Femto wich I plane to use is Alcatel. My primary target is Packet core, so femto-osmohnbgw-osmosgsn(osmo-hlr)-osmoggsn. Alredy know this want be easy task, But I will try, I expect also problem with SIM authentication. In past I did protocol simulators in Python (Gb, S11, Gn, Gx, Gy), wich were used in production for testing. When I hopfuly install osmo-iuh, I wll conect femto to it and try to configure it, will sniff trafic via wireshark between and check whats happening, Now I will try to rebulid IuH again. BR Goran The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.

3 7

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC September 2017