OpenBSC November 2018

openbsc@lists.osmocom.org

23 participants
37 discussions

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

08 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

voting in gerrit: merge at +3? (+2+1 / +1+1+1)
by Stefan Sperling 12 Dec '18

12 Dec '18

There has been some face-to-face discussion about Osmocom's code review process within sysmocom recently. I am posting to this list now with the consent of everyone involved so far, in order to involve the Osmocom community at large in this discussion as well. There has been a lack of code review from people who don't have "+2" super powers in Gerrit. This applies to anyone among us, independently of any individual's relationship with sysmocom. The bulk of the work involved in reviewing code falls on Harald's shoulders, with Pau and Neels sharing most of the rest between themselves. At present, while people who add a +1 have their voices heard, their input does not formally affect the decision to merge a change. A change still has to pass by the pre-selected +2 gatekeepers in order to be merged, no matter how many other people have provided input. The implication for developers without +2 powers is that their time is more effectively spent on advancing their own changes towards a +2 vote, rather than spending time on whatever else is waiting in Gerrit. This may not apply to everyone, of course. But at least for me, this is certainly the case; I have only been reviewing other people's patches when I was explicitly asked to do so. Myself and several other developers hope that with a change to our review process we can fix this inertia, spread code review across more shoulders and encourage more collaborative code review in Osmocom. The basic idea is that everyone's input should count for something. If those among us with +1 powers were given a partial say on the fate of every change, our decisions will carry more weight and our influence within the project will slightly increase. We'd also be encouraged to step out of our own corners of expertise every now and then, and look at what other developers are working on. On the flip side, this means we'd carry more responsibility than we do now. We wouldn't always be relying on our +2 gate keepers and would have to apply our own judgement more carefully. The concrete proposal is to make votes in Gerrit accumulative. Each change would require a total score of +3 to be merged. This score can consist of either a +2 and a +1 vote, or three +1 votes; and no -1 votes. Also, +2 developers would keep their ability to unilaterally block or revert changes under this new model. They'd keep their existing role as arbiters in case of disputes. Max figured out how Gerrit could be configured for this behaviour. It involves Prolog code, but since we're all quite smart we should be able to figure that out, right? https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html#_… We'd be interested to hear what the community thinks about this proposal. Thanks, Stefan

7 43

Info on Alcatel Femtocells
by Alex 30 Nov '18

30 Nov '18

Hi to everyone! I'm a new member and I really appreciate the work done here! I'm trying to use Alcatel Femtocells (ALU 9361/9362/9363) with osmo-hnbgw, but I'm still blocked at the IPSEC tunnel step. I've created an IPSEC server with EAP support, but I suspect there is a problem with my self signed certificate. Probably the femtocell has an internal trusted CA which validates server certs. I din't find the console pins on the board also, so I cannot simply connect to it and have a look at the system level. Has anyone any experience with this kind of HW or just an idea about a possible work around? Thank you and best regards Alex

2 6

HEADS UP: don't merge .adoc or vty ref changes to osmo-gsm-manuals.git anymore!
by Neels Hofmeyr 28 Nov '18

28 Nov '18

The adocs and vty reference content from osmo-gsm-manuals.git has been "moved" to the individual project repositories. That means if you apply more .adoc changes to osmo-gsm-manuals.git, we have to port that to the new location. (The content is not yet removed from osmo-gsm-manuals.git, so you might run into believing the move hasn't happened yet.) You can already edit in the individual osmo-bsc,-msc,... repositories, and build with 'configure --enable-manuals'. The jenkins publishing job isn't updated yet, should follow soon. right, osmith? ~N

3 4

nanoBTS fails to start with osmo-bsc
by Pierre Kim 27 Nov '18

27 Nov '18

With the newest git repo version of osmo-bsc, my nanoBTS fails to start. I can confirm that they work normally with ip.access softBSC. I thought osmocom Redmine issue #3063 might be relevant and tried setting/unsetting force-combined-si but I am still getting the same result. Attached are the packet capture and bsc config file The following is the log from osmo-bsc: <0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port 3002 <0004> abis_nm.c:847 OC=BTS(01) INST=(ff,ff,ff): GET ATTRIBUTE NACK <0004> osmo_bsc_main.c:178 BTS0 does not support Get Attributes OML message. <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[0/5]: 168a004 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[1/5]: 168a002 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[2/5]: 168a002 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[3/5]: 168a001 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[4/5]: 168a001 is v136d0 <0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is unreported <0004> abis_nm.c:2888 (bts=0,trx=0) IPA RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 <0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port 3003 <0003> osmo_bsc_main.c:283 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 600 using MCC-MNC 450-09 LAC=23 CID=0 BSIC=63 BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1149 **** ** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType ) ** IPA_SW_FATAL_ERROR ** In task "TRX Proc:L2_BCH" @ (325). **** . 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#1149 (325). BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31782: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=31782:WARN:OAM_RES:trx_fatal_error_log.c#256:TRX Proc:L2_BCH:l2_bch.c#1149 (325)

2 2

cellmgr-ng rotten (Re: Build failed in Jenkins: master-cellmgr-ng » a1=default,a2=default,a3=default,osmocom-master-debian9 #54)
by Pau Espin Pedrol 24 Nov '18

24 Nov '18

Hi all, I started looking at this failure and found out code in this repository is really old, with nobody maintain it (13 months since last commits?). I started by updating the contrib/jenkins.sh to use osmo-build-dep.sh and osmo-clean-workspace.sh like we do in other repos, because i felt it was not building up to date stuff. After updating that script, indeed it seems cellmgr-ng cannot be built against new libosmo-sccp due to some M3UA headers /API changes. There's even a tag during that commit in libosmo-sccp called "old_sua". After that commit, cellmgr-ng fails to build. If I try to build it against "old_sua", still cannot build fine with updated contrib/jenkins.sh script due to missing LIBOSMOSCCP_CFLAGS in tests/Makefile.am, and then still other headers are not found in other places, etc. I stopped at this point because I'm starting to spent too muhch time on this and it seems nobody is using it anyway. Can we disable the build of this project? Does somebody want to take care of it? Regards, Pau -- - 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

2 1

3G with Asterisk connection
by Pierre Kim 21 Nov '18

21 Nov '18

Hello, I'm setting up an Asterisk connection with osmo-sip-connector. Initiation of calls works fine, but no sound is getting through. My setup is as follows: Local computer is running all osmo software plus asterisk interface has IP address 192.168.27.49 plus 192.168.27.47 as alias femtocell is at 192.168.27.41 osmo-mgw.cfg mgcp bind ip 192.168.27.49 rtp port-range 4002 16000 rtp bind-ip 192.168.27.47 osmo-sip-connector.cfg sip local 192.168.27.47 5069 remote 192.168.27.49 5060 osmo-msc.cfg msc mgw remote-ip 192.168.27.49 mgw remote-port 2427 mgw local-port 2728 When I start wireshark it only shows packets flowing between 192.168.27.41(femtocell) and 192.168.27.47(osmo-mgw). No packets to/from Asterisk server, how can I fix this problem? Current documentation on osmo-mgw is quite difficult to understand.

2 3

GSUP protocol manual in HLR, MSC, SGSN
by Neels Hofmeyr 20 Nov '18

20 Nov '18

(cross-posting so it doesn't get lost) reading Vadim's patches, I just now invented: https://osmocom.org/issues/3700 "Idea: have a separate GSUP manual" Provide feedback at that issue if you have an opinion... ~N

1 0

3G data connection loss
by Pierre Kim 20 Nov '18

20 Nov '18

Hello, I've set up a mini 3G RAN with yesterday's git repo. The phone works fine and successfully creates a PDP context, but data only works for a few minutes before it stops. Logs from SGSN and GGSN are as follows. Any help will be appreciated. >From SGSN: <000e> sgsn_libgtp.c:175 PDP(450091417013617/0) Create PDP Context <0018> iu_client.c:530 handle_co(dir=4, proc=0) <0018> iu_client.c:530 handle_co(dir=1, proc=11) <0018> iu_client.c:530 handle_co(dir=2, proc=1) <0018> iu_client.c:507 handle_co_initial(dir=1, proc=19) <0018> iu_client.c:530 handle_co(dir=2, proc=6) <0002> gprs_gmm.c:208 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x221bd60]{Init}: Event IU Security Command Complete received. not permitted <0018> iu_client.c:599 Error in cn_ranap_handle_co (-1) <0018> iu_client.c:530 handle_co(dir=1, proc=20) <0018> iu_client.c:530 handle_co(dir=4, proc=0) <0018> iu_client.c:530 handle_co(dir=1, proc=11) <0018> iu_client.c:530 handle_co(dir=2, proc=1) <0018> iu_client.c:507 handle_co_initial(dir=1, proc=19) <0018> iu_client.c:530 handle_co(dir=2, proc=6)<0002> gprs_gmm.c:208 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x221bd60]{Init}: Event IU Security Command Complete received. not permitted <0018> iu_client.c:599 Error in cn_ranap_handle_co (-1) <0018> iu_client.c:530 handle_co(dir=1, proc=20) <0018> iu_client.c:530 handle_co(dir=4, proc=0) <0018> iu_client.c:530 handle_co(dir=1, proc=11) <0018> iu_client.c:530 handle_co(dir=2, proc=1) <0023> gtp.c:2800 Packet from 192.168.27.46:2152, length: 95 content: 32 ff 00 57 00 00 00 05 11 b4 00 00 45 00 00 53 ad fc 40 00 38 06 7b 5c 17 23 dd 7e c0 a8 64 02 01 bb cf 8c 78 70 5c a6 c2 6b 46 39 80 18 01 fc 05 54 00 00 01 01 08 0a 9f 6b cd 80 ff ff 61 96 15 03 03 00 1a 6e ec c9 35 4b a9 48 c5 23 b0 fa 35 a5 d6 e7 e5 5b 95 f0 38 45 0a cf c8 97 d1 : Unknown PDP context, GTPv1 <0023> gtp.c:2800 Packet from 192.168.27.46:2152, length: 64 content: 32 ff 00 38 00 00 00 05 11 b5 00 00 45 00 00 34 ad fd 40 00 38 06 7b 7a 17 23 dd 7e c0 a8 64 02 01 bb cf 8c 78 70 5c c5 c2 6b 46 39 80 11 01 fc dd ce 00 00 01 01 08 0a 9f 6b cd 80 ff ff 61 96 : Unknown PDP context, GTPv1 GGSN <0002> ggsn.c:735 PDP(450091417013617:5): Successful PDP Context Creation: APN=internet(internet), TEIC=1, IPv4=192.168.100.2, IPv6=none <000d> gtp.c:2761 Packet from 192.168.27.49:2152, length: 24 content: 32 1a 00 10 00 00 00 00 11 b4 00 00 10 00 00 00 05 85 00 04 c0 a8 1b 31 : Received Error Indication <0002> ggsn.c:372 PDP(450091417013617:5): Deleting PDP context <000d> gtp.c:2755 Packet from 192.168.27.49:2152, length: 24 content: 32 1a 00 10 00 00 00 00 11 b5 00 00 10 00 00 00 05 85 00 04 c0 a8 1b 31 : Unknown PDP context <000d> gtp.c:2117 Packet from 192.168.27.49:2123, length: 52 content: 32 12 00 2c 00 00 00 01 4c 0a 00 00 0e 13 10 00 00 00 05 14 05 85 00 04 c0 a8 1b 31 85 00 04 c0 a8 1b 2a 87 00 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : Unknown PDP context: 1 <000d> gtp.c:2800 Packet from 192.168.27.42:2152, length: 72 content: 32 ff 00 40 00 00 00 01 00 00 00 00 45 00 00 3c 6f 51 40 00 40 06 08 fb c0 a8 64 02 d8 3a c5 8a cb 5a 01 bb 7a dc a8 09 00 00 00 00 a0 02 ff ff ce 3c 00 00 02 04 05 b4 04 02 08 0a ff ff c7 58 00 00 00 00 01 03 03 06 : Unknown PDP context, GTPv1 <000d> gtp.c:2800 Packet from 192.168.27.42:2152, length: 72 content: 32 ff 00 40 00 00 00 01 00 01 00 00 45 00 00 3c 6f 52 40 00 40 06 08 fa c0 a8 64 02 d8 3a c5 8a cb 5a 01 bb 7a dc a8 09 00 00 00 00 a0 02 ff ff cd 42 00 00 02 04 05 b4 04 02 08 0a ff ff c8 52 00 00 00 00 01 03 03 06 : Unknown PDP context, GTPv1 <000d> gtp.c:2800 Packet from 192.168.27.42:2152, length: 72 content: 32 ff 00 40 00 00 00 01 00 02 00 00 45 00 00 3c 6f 53 40 00 40 06 08 f9 c0 a8 64 02 d8 3a c5 8a cb 5a 01 bb 7a dc a8 09 00 00 00 00 a0 02 ff ff cb 4d 00 00 02 04 05 b4 04 02 08 0a ff ff ca 47 00 00 00 00 01 03 03 06 : Unknown PDP context, GTPv1

3 6

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2018