OpenBSC March 2018

openbsc@lists.osmocom.org

16 participants
40 discussions

Re: Help with sccp library
by mosbah abdelkader 07 Jul '25

07 Jul '25

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

4 3

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

nanoBTS constantly restarting
by Michael Spahn 02 Jun '18

02 Jun '18

Hello all, I have recently tried migrating an OsmoNITB setup to the new standard using mostly this guide right here: https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I… <https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I…> However, while my nanoBTS works perfectly fine in the old setup, it just doesn not work at all in the new one. When I start osmo-bsc the LED on the BTS starts flashing green after a few seconds and then stops flashing and just stays green all the time, which is the expected behaviour. Unfortunately though, after another couple of seconds, the LED starts flashing green again and then turns red. This is what the log shows: BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1154 **** ** l2_bch.c#1154:BCHbcchSItypeValid( prim_p->infoType ) ** IPA_SW_FATAL_ERROR ** In task "TRX Proc:L2_BCH" @ (1063). **** 　 . BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=TRX Proc:L2_BCH:l2_bch.c#1154 (1063). BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31385:WARN:OAM_RES:trx_fatal_error_log.c#255:TRX has logged the error: 　 . BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31385:WARN:OAM_RES:trx_fatal_error_log.c#256:TRX Proc:L2_BCH:l2_bch.c#1154 (1063) . BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=BCHbcchSItypeValid( prim_p->infoType ). BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31385:WARN:OAM_RES:trx_fatal_error_log.c#260:BCHbcchSItypeValid( prim_p->infoType ) 　 20180328072641280 DLINP <0013> input/ipaccess.c:247 Sign link vanished, dead socket 20180328072641281 DLINP <0013> input/ipaccess.c:71 Forcing socket shutdown with no signal link set 20180328072641282 DCTRL <000e> osmo_bsc_ctrl.c:160 No more BTS connected, sending TRAP. 　 Now I'm not claiming that my config is already 100% correct but I feel like this isn't a configuration issue. I'm using the most recent nightly builds of the entire osmocom library. Does anyone know what could be at fault here? Kind regards, Michael Spahn

4 9

Problems with A5/3 encryption
by Bruckner Jan (ETAS-SEC/ECT-Mu) 19 Apr '18

19 Apr '18

Dear list, I'm having trouble using the A5/3 encryption in my setup. A5/1 works perfectly fine [attachment a5_1.pcapng]. As soon as I switch to A5/3 and e.g. send an SMS, the last valid message I see in the Wireshark traces of the GSMTAP of osmo-bts-trx is the Ciphering Mode Command requesting A5/3. After that, several messages arrive at the bts, but it seems like it can't make any sense of them. The MS repeatedly tries to send the SMS but never succeeds [attachment a5_3.pcapng]. Both MSs are connected to the same bts. According to the Classmarks of all MSs, A5/1 as well as A5/3 are supported. This is my Setup: - USRP N210 - osmo-trx - osmo-bts-trx - osmo-nitb - osmo-pcu - osmo-sgsn - osmo-ggsn I'm using a Debian 9 VM and tried both the packages from osmocom-latest as well as osmocom-nightly. The MSs I've tested are two Nexus 6 and one Samsung Galaxy S I9000. All three with sysmocom nano USIMs. Could the decryption at the bts be incorrect? Has anyone tested/used it recently? I'll be happy to provide additional information if needed. Thanks, Jan

3 7

MO-SMS Maximum Number of Characters for OSMO-NITB and OSMO-BSC less than 60?
by Ron 16 Apr '18

16 Apr '18

Hi All, Can anyone confirm if the maximum MO-SMS that can be sent is less than 60 characters including spaces? For OSMO-NITB, we reach a maximum of 59 characters for MO-SMS, while for OSMO-BSC, we only reach a maximum of 50 characters (MO-SMS). Is this a known issue? TIA. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

3 3

New (but unofficial) asn1c has been applied to osmo-iuh
by Chiu Bi-Ruei 29 Mar '18

29 Mar '18

Dear All, I have just uploaded my modified osmo-iuh, which a new version asn1c is applied, to : https://github.com/brchiu/osmo-iuh/tree/new-asn1c Code generated by this new asn1c can handle necessary ASN.1 information object class feature used in several 3gpp specs, thus it remove the need of asn1tostruct.py. Because Lev Walkin has not accepted corresponding pull requests yet, it should be built from Velchkov's repository : https://github.com/velichkov/asn1c/tree/s1ap And link to new libasn1c : https://github.com/brchiu/libasn1c/tree/new-asn1c I use RANAP 14.1.0, RUA 14.0.0 and HNBAP 14.0.0 to generate files. There are still several compilation error which are irrelevant to this new asn1c. https://gist.github.com/brchiu/17b5d306dd3e95f5e7b255a7dbb81344 Hope someone can help solving them. Because I do not have test environment nor have no time to verify this porting, you are welcomed to use this result on your own. thanks. regards, Bi-Ruei, Chiu.

2 1

git.osmocom.org read-only during migration
by Harald Welte 28 Mar '18

28 Mar '18

Hi all, I've set git.osmocom.org to read-only while I'm doing the migration to the new server. So don't be surprised if you won't be able to push there (or if gerrit is not able to push there). I'll try to make this quick, should be back within the afternoon. -- - 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 2

general review of FSMs across the code base
by Neels Hofmeyr 26 Mar '18

26 Mar '18

When libosmocore/contrib/fsm-to-dot.py hinted me at errors in the new gscon FSM in osmo-bsc, I took a moment to render and look at all our FSM definitions. The osmo-bsc ones are fixed by https://gerrit.osmocom.org/7501 I also found OS#3110 and OS#3111 I published the FSM graphs as rendered today at http://people.osmocom.org/neels/osmo_fsm_graphs/ and might do so every now and then. If anyone likes, we could do it from jenkins regularly. ~N

1 0

"lai_and_lac"
by Neels Hofmeyr 26 Mar '18

26 Mar '18

Hi stsp, I noticed in the recent gsm0808_cell_id_list2 a review item slipped by: A "LAI" is by definition a PLMN (MCC+MNC) plus a LAC. So saying "LAI and LAC" is like saying "My family and my brother". So maybe we want to rename the "lai_and_lac" member of struct gsm0808_cell_id_list2 before it gets tagged for release. Just "lai" would be accurate, as its type (struct osmo_location_area_id) suggests. ~N

2 2

OSMO-BTS-TRX: Cannot send payload with invalid length! (expecting 15, received 14)
by Ron 23 Mar '18

23 Mar '18

Hi Support, In Half Rate configuration of OSMO-BSC, is there a way to used ETSI TS 101 318 standard for its RTP Payload Format? As per testing, the RTP Payload format used by OSMO is RFC5993. Can this be configured in OSMO-BSC or OSMO-BTS-TRX? Or the configuration of this is hard coded? Logs from OSMO-BTS-TRX: [0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) [0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) [0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) [0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) [0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) [0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) [0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) [0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) [0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) [0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) [0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) [0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) [0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) TIA! Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC March 2018