OpenBSC August 2017

openbsc@lists.osmocom.org

19 participants
44 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

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

11 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

OpenBSC USSD external application
by Rowan Phipps 16 Sep '17

16 Sep '17

Hi, I’ve been looking into getting ussd working with an external application. I found a branch from last year (fairwaves/sup-ussd) that looks like it has implemented most of ussd sessions and possibly communicates with an external application. Does anyone know if it was finished or what still needs to be done? I also found a python script called ussd_example.py which looks like it is supposed to act as a gateway and receive used connections from openbsc. Is this correct and did it work or am I misunderstanding its purpose? Thanks! - Rowan Phipps

3 4

catch-22 VTY error
by Neels Hofmeyr 08 Sep '17

08 Sep '17

I'd like to share a VTY config error analysis that has a tricky solution: I started osmo-bsc -c osmo-bsc.cfg with, according to openbsc/doc/examples/osmo-bsc: net [...] bts 0 [...] periodic location update 30 trx 0 [...] and get this error: There is no such command. Error occurred during reading below line: trx 0 what? 'net / bts / trx' is no command?? Solution: I'm on the vlr_3G branch (incorporating 2G via A-interface) and on this branch, I've actually moved the 'periodic location update N' command a level up, from net / bts / periodic to net / periodic (background: assuming that OsmoMSC does not have individual BTS info, we moved some settings up to network level; whether this makes sense for osmo-bsc is a different question, it's just what happens to be on the vlr_3G branch now). So there is no net / bts / periodic command. Why do I get an error for net / bts / trx instead? two reasons: 1. 'trx 0' was the line following the 'periodic' command, 2. since 'periodic' exists one level above, the vty code goes to the parent node automatically. About 2: we tend to indent our VTY config files, but in fact the indentation has no effect whatsoever, it is just eye candy (very useful eye candy). The code in question: If a command does not exist, try 'vty_go_parent()' and see if the command exists there. That's what allows us to omit 'exit' in our config files to go to the parent node explicitly: libosmocore/src/vty/command.c: int config_from_file(struct vty *vty, FILE * fp) { int ret; vector vline; while (fgets(vty->buf, VTY_BUFSIZ, fp)) { vline = cmd_make_strvec(vty->buf); /* In case of comment line */ if (vline == NULL) continue; /* Execute configuration command : this is strict match */ ret = cmd_execute_command_strict(vline, vty, NULL); /* Try again with setting node to CONFIG_NODE */ while (ret != CMD_SUCCESS && ret != CMD_WARNING && ret != CMD_ERR_NOTHING_TODO && is_config_child(vty)) { HERE -----> vty_go_parent(vty); ret = cmd_execute_command_strict(vline, vty, NULL); } cmd_free_strvec(vline); if (ret != CMD_SUCCESS && ret != CMD_WARNING && ret != CMD_ERR_NOTHING_TODO) return ret; } return CMD_SUCCESS; } In this case the 'periodic...' command does in fact now exist one level above, so the vty_go_parent() is successful and running that command works. But, the vty config parsing then sits above on the 'network' level, is no longer in 'bts 0' and hence refuses to accept the following bts-level command, in this case 'trx 0'. Confusing! So it's not a bug, it's a feature. But it's a feature we might see quite often if we move the 'periodic' command up to network level and users attempt to use their old config files. Same goes for the 'timezone' command, BTW, so we might want to rename commands, or re-consider moving commands one level up in the first place. Maybe we should leave backward compat catchers in place that print a warning. ~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

2 4

jenkins build slaves: Rationale for some builds in docker vs. some not?
by Harald Welte 06 Sep '17

06 Sep '17

Hi! We have some builds that happen inside a docker, and some that happen natively on the (Debian 8) build slave. Can somebody involved with this illustrate why that is the case, and what's the rationale here? Just looking at the setup, I'm unable to figure out whether there's any particular reason for this, or whether it's simply "we started without and then did some builds in docker but nobody migrated the other builds over" >From my point of view, I would have assumed that building in different containers would make sense to e.g. build on different distributions / versions, or building against older libosmo* vs. building against libosmo* from nightly package feeds vs. re-building all dependencies from master. But it appears that only a single container is built, and that container is used for some jobs (like osmo-msc-gerrit) but not for other jobs. If I missed some wiki page or mailing list posts with related information, a pointer would be helpful. Thanks in advance. 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)

4 5

about merging deletion of checking-value-strings script from libosmocore
by Neels Hofmeyr 02 Sep '17

02 Sep '17

I would have welcomed more patience in merging https://gerrit.osmocom.org/3685, "Use value string check from osmo-ci" in libosmocore. (the commit log of which fails to indicate removal of the script, btw) Moving to the new repositories, I have enough loose ends flapping in the wind, and dropping the script from libosmocore has added yet another distraction, while not being necessary to start using the one from osmo-ci. Max clearly posted "N. B: this should be merged last, after all the repos converted to check script from osmo-ci." -- which is not the case for the new repositores split from openbsc.git. In osmo-msc I have >50 patches waiting to be merged. The timing could hardly have been worse, luckily only a few gerrit builds are affected. Will try to sort out merging of the patches without needing a rebase and >50 rebuilds. Thanks for you attention :) ~N

2 2

RFC: use git-version-gen from gnulib
by Max 02 Sep '17

02 Sep '17

Hi. I'd like to propose to switch from local (unmaintained?) copy of git-version-gen script and use it directly from upstream gnulib package. It's available pretty-much everywhere (including ancient Debian which we support for nightly). It's also available in meta-oe: https://layers.openembedded.org/layerindex/recipe/47365/ It doesn't feel right to use copy-pasted code when we could offload the maintenance work to packaging/dependency tools. What do you think? Please contribute to https://osmocom.org/issues/2467 which I've created to track this RFC. -- 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 2

[PATCH] test/common.sh: fix typo in gapk binary location
by Vadim Yanitskiy 31 Aug '17

31 Aug '17

--- test/common.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/common.sh b/test/common.sh index 39cdd7d..591be3a 100644 --- a/test/common.sh +++ b/test/common.sh @@ -4,7 +4,7 @@ REFDIR=./ref-files if [ -f ../src/gapk ]; then GAPK=../src/gapk elif [ -f `which gapk` ]; then - GAPK=`whiich gapk` + GAPK=`which gapk` else exit 1 fi -- 2.14.1

3 2

redmine e-mails broken from 08/26 through 08/31
by Harald Welte 31 Aug '17

31 Aug '17

Dear Osmocom community, from August 26th 06:54 UTC through August 31st 06:22 UTC our Osmocom.org redmine could not send any e-mails. This was due to a configuration file syntax error introduced by me, my apologies. If you rely on redmine e-mail notifications to the issues you have subscribed to, please double-check as related notifications during that interval were unfortunately lost. Best regards, Harald p.s.: The reason for the config change was to enable e-mail notifications from jenkins.osmocom.org (which it now has, if you want to configure e.g. post-build notification actions). -- - 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)

1 0

Wanted: OpenBSC / Osmocom users in Pakistan?
by Harald Welte 31 Aug '17

31 Aug '17

Hi All! I'm wondering if there are any users of the Osmocom cellular stack in Pakistan around. If so, please kindly follow-up by private mail, as there might be some projects in which your help would be appreciated. Thanks in advance. 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)

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC August 2017