OpenBSC May 2019

openbsc@lists.osmocom.org

10 participants
23 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

Problem while running NIB on Open Cellular Base sation
by Brackley Casinga 31 Jan '24

31 Jan '24

Hi, My name is Brackley Cassinga Form DRC, we run a community network called pamoja net where we offer gsm services using osmocom open source software and OC Base station. Recently I have tried to install another base station as the same installed but I could not find any resource guiding through all the steps to take to run NIB on a base station. I'm currently running Ubuntu and I will appreciate if you could guide me on the installation of BSC,hlr,MSC , in order to run a basic gsm network. Thank you. Regards -- *Ir Brackley heshima Casinga **Pacifique* *CEO and Founder of kwanzatechnologie* KwanzaTechnologies ,GlobalElectronics +243977265291 | +243977265291 | Pcassinga(a)gmail.com/ brackley(a)ensemblepourladifference.org www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> | Skype: Brackley cassinga <https://webapp.wisestamp.com/#> Av Semliki N 43

2 1

OpenBSC on 3rd party MSC
by wyao＠corrections.com 29 Jul '19

29 Jul '19

Hello All, I am working on get OpenBSC connected to a 3rd party MSC, I read from the Osmo document that I can use the bsc only mode and the osm-bsc instead of the osmo-nitb. Currently I had osmo-trx-uhd, osmo-bts-trx, osmo-bsc, and osmo-stp configured and and running, but I see a lot of below error logs in the osmo-stp console: ``````````````````````````` DLSS7 <000c> osmo_ss7.c:1468 asp-asp-dyn-0: xua_srv_conn_cb(): sctp_recvmsg() returned 56 (flags=0x80) DLM3UA <000f> m3ua.c:722 asp-asp-dyn-0: Received M3UA Message (XFER:DATA) DLM3UA <000f> m3ua.c:541 asp-asp-dyn-0: m3ua_rx_xfer DLM3UA <000f> m3ua.c:580 asp-asp-dyn-0: m3ua_rx_xfer(): M3UA data header: opc=337=0.42.1 dpc=185=0.23.1 DLSS7 <000c> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=185=0.23.1 not local, message is for routing DLSS7 <000c> osmo_ss7_hmrt.c:258 MTP-TRANSFER.req for DPC 185: no route! ```````````````````````````` On the BSC console, I am seeing a lot of: ``````````````````````````````` <0007> a_reset.c:106 A-RESET(msc-0)[0xb76ce0]{DISC}: (re)sending BSSMAP RESET message... <0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP ``````````````````````````````` Can anyone identify what is the issue here? Appreciates! Regards, Weiqi

3 4

OpenBSC installed but missing ipaccess and abisip-find
by ty 28 Jun '19

28 Jun '19

Hello. I just followed the step by step procedure outlined in the wiki to compile OpenBSC on Ubuntu 16.04 LTS for the ip.access nanoBTS. My problem is that the folder ipaccess which has the ipaccess.config is missing and so is the abisip-find file. Any leads on why this is happening? I had seen somewhere that the above can be found in the osmocom-ipaccess-utils from the repo but that too is unavailable. Many thanks -tyrus

5 8

RFC: Quoted strings with spaces in CTRL protocol?
by Harald Welte 25 May '19

25 May '19

Hi! I've been working on a patch for OsmoBSC which generates CTRL traps from OML Failure Event Reports as received from BTSs. This is quite obvious, of course we want failures generate traps, right? The problem starts with the fact that Failure Event Reports can contain arbitrary strings ("Additional Text IE"), and that such text of course can contain spaces. My current patch (https://gerrit.osmocom.org/#/c/osmo-bsc/+/14177) would produce TRAPs like this: b'TRAP 0 bts.0.oml_failure_report "processing failure","failure ceased","TC_pcu_oml_alert"' [where the b'' part is from python as I used osmo_ctrl.py to print the above] As we never formally specified anything about the CTRL protocol apart from using ',' as a separator between fields, this is a somewhat grey area. What do you guys think? Do you know of existing CTRL interface usage where spaces are present in the 'value' part of the message? Do you know of existing code that would break should we introduce support for quoted strings with spaces inside the 'value' part? 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

New features without tests :/
by Harald Welte 24 May '19

24 May '19

Dear fellow Osmocom developers, I just would like to use this as a gentle reminder that we shouldn't be merging new features without having automatic tests for them in place. What comes to my mind immediately right now (but I'm sure there are other examples) is the "subscriber create on demand" feature. I couldn't find any tests in HLR_Tests.ttcn about this feature. What this means is, that it will *eventually* break unnoticed, particularly until somebody is using that feature and updating frequently to master, which is unlikely to happen. Either you run a production system and then you don't follow master, or you're just playing around and then that feature is probably not something you'd be using in many cases. What actually bugs me most about it, is that the tests should have been written first. For most of our development [1], the existing infrastructure in terms of TTCN3 Modules is very strong, and adding related tests is rather quick. This means it's *very* feasible to write the tests first and then the actual code. In fact, my own experience shows that development is much faster this way, as maual testing of the entire stack with phones is sloooow. This is not to complain to Oliver or any single person, but just a general reminder to all of us. That includes first and foremost myself as I'm merging most of the development, but is addressed to all of the developers and reviewers: IF something doesn't have a test, but could reasonably be tested without spending a multitude of the development time on tests, we should mandate that tests are available at the time of merge. We of course cannot mandate or enforce that developers write the tests first and follow test-driven development methodology. But I would at least strongly encourage everyone to try that. If you first spend tons of time with manual testing and then write a test case, it's much less efficient as you spend time for both. OTOTH, if you first invest the time into writing the test, then the development can make very quick progress and you save a lot of time that would otherwise be wasted with manual testing. Regards, Harald [1] I'm referring to rather self-cntained, small features. For sure, e.g. testing inter-MSC-HO requires lots of new tsting infrastructure to be developed, as does testing of the PCU. So yes, there are exception. -- - Harald Welte <hwelte(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

osmo_fsm and time_t
by Harald Welte 23 May '19

23 May '19

Hi Neels, in the following commit: commit 89991fdb7c01fa42e323577b4026985e580763cf Author: Neels Hofmeyr <neels(a)hofmeyr.de> Date: Mon Jan 28 19:06:53 2019 +0100 you introduce language about restricting the timeout to a signed 32bit value, as time_t is not well-defined on 32bit systems. What I'm somehow missing is where we are using time_t in this context? Neither osmo_fsm code nor the underlying osmo_timer_list seems to be using time_t. So why would we bother about time_t here? Thanks for sharing your thoughts. 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 1

osmo_fsm and sub-second timeouts
by Harald Welte 18 May '19

18 May '19

Hi all! As some of you know, I'm currently using libosmocore, and specifically osmo_fsm inside some cortex-m microcontroller projects. One of the features I need there: FSM timeouts below 1s. osmo_fsm uses osmo_timer_list as underlying timer, and that timer can express any timeval (seconds + microseconds) as timeout. Only the osmo_fsm API doesn't expose that part. What I could now do: Simply add osmo_fsm_inst_state_chg2 which takes one more argument for microseconds. However, I find that "second, microsecond" style with two arguments everywhere quite clumsy. So what I'm instead suggesting is to add new API that use one single timeout value (like the current API), but specify the timeout in milliseconds. The old API then becomes a wrapper around the new API, simply multiplyin timeouts by a factor of 1000. Does anyone think this is too restrictive? I currently cannot think of use cases where timeouts below one 1ms or with granularity below 1ms matter *and* where one would want to use osmo-fsm. But given how speeds of systems (both processors and communications systems) are increasing, it might be that we'd eventually need that? I'd currently assume osmo_fsm with all of its internal logging, etc. is too heavy-weight for such super-time-constrained use cases. And in terms of value range: Assuming a 32bit architecture, the scale of a 2^32 microsecond value is sufficient to express timeouts up to 1193 hours, which in turn is about 49 days. Any comments, ideas, thoughts? 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

External clock source for LimeSDR mini
by Rafael Diniz 08 May '19

08 May '19

Hi all, Could anyone advise me which solution should I look for feeding the LimeSDR mini with external clock GPSDO locked? Btw, which you think it's a better option for a home brew BTS: the LimeSDR mini with external clock plus an intel mini-pc, or the LimeNet mini? Cheers, Rafael Diniz

1 0

ttcn3: bsc-sccplite
by Neels Hofmeyr 08 May '19

08 May '19

Looking at https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-sccplite/… looks quite horrible since build 357. However, with my own manual tests, all of those pass. It looks like most of those failures are sporadic, and I cannot reproduce them. I am not sure how to find out what is going there, I can just say that osmo-bsc looks quite stable AFAICT and that it seems to be non-determinism / timing in the ttcn3 and/or system load causing the failures. ~N

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC May 2019