OpenBSC November 2018

openbsc@lists.osmocom.org

23 participants
34 discussions

osmo-gsm-manuals in project repos: I see no .pdf
by Neels Hofmeyr 28 Nov '18

28 Nov '18

Hi Oliver, so I merged the stuff to add the manuals to the individual git repositories, since you said that it works. But when I do --enable-manuals I don't see any PDF files generated. Also a manual 'make pdf' says "nothing to be done". (I probably should have tried it before merging after all) So what am I doing wrong? Alternatively, can you fix it please? ~N

2 2

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

26 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 23 Nov '18

23 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

SMS: UCS-2 concatenation with UTF16 emoticons
by Keith 20 Nov '18

20 Nov '18

Hi all, I noticed that SMS with emoticons on the boundary of the concatenated segments are not displaying correctly on the destination handset. * - imagine the disaster when that kiss-blowing smiley face thing at the end of your SMS turns out as a diamond with a ? for the recpipient! OMG, the potential butterfly effect is too much to think about... :)) So... This is my analysis: We have 140 bytes for the message, less the 6 bytes for the user header data in the case of concatenated SMS , leaving 134 bytes. It's well know that this means 67 characters per segment for an SMS using UCS-2 encoding. But, it we fill the message with emoticons that are using 4 bytes per 'character', then we have space for 134/4 = 33 and a half. Ooops. Still, the destination handset should reassemble the message and stick the two "halves" of the emoticon together, right? - except I'm not observing this. To rule out us doing something wrong in osmo, I wonder might somebody else (who has an unlimited SMS package) from a commercial provider try sending some crafted SM from one emoji-enabled phone to another, something like this: 😱abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123😱56789 That's likely going to get mangled by mailing list or your mua, so it is: [4 byte emoji]abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123[4 byte emoji]56789 You could also try various messages filled with emojis. Of course, if you bring up your osmo network with SMPP-mirror you can watch the trace in wireshark, you'll see when the last emoji gets chopped in two. You could try the same message on osmo and your commerical network. If it's actually a problem of the phones, you should get [4 byte emoji]abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123[two diamonds with ?]56789 Thanks! Keith.

4 4

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

20 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 19 Nov '18

19 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

Help with silent call
by Snehasish Kar 19 Nov '18

19 Nov '18

Hello I have read that silent-calls in GSM can be used to make a call to a target MS and listen to it without having the target knowing it. Is this theoretically possible ? If yes, can it be done in OpenBSC or any such way exists to do this or any other alternative does exists? BR Snehasish

3 4

Failing test cases (and builds) on other architectures in Debian
by Ruben Undheim 19 Nov '18

19 Nov '18

Hi, Most of the openbsc packages are now up-to-date in Debian! : https://qa.debian.org/developer.php?email=Debian-mobcom-maintainers%40lists… , but there are a few failing builds on some officially supported Debian architectures (mostly failing test suites): osmo-bsc: - mips (https://buildd.debian.org/status/fetch.php?pkg=osmo-bsc&arch=mips&ver=1.2.1…) ("gsm0408" and many "handover" tests failing) - s390x (https://buildd.debian.org/status/fetch.php?pkg=osmo-bsc&arch=s390x&ver=1.2.…) ("gsm0408" and many "handover" tests failing) osmo-iuh: - mips (https://buildd.debian.org/status/fetch.php?pkg=osmo-iuh&arch=mips&ver=0.3.0…) ("helpers" and "ranap" tests failing) - s390x (https://buildd.debian.org/status/fetch.php?pkg=osmo-iuh&arch=s390x&ver=0.3.…) ("helpers" and "ranap" tests failing) osmo-msc: - mips64el (https://buildd.debian.org/status/fetch.php?pkg=osmo-msc&arch=mips64el&ver=1…) ("msc_vlr_test_gsm_ciph" test failing) - mipsel (https://buildd.debian.org/status/fetch.php?pkg=osmo-msc&arch=mipsel&ver=1.2…) ("msc_vlr_test_gsm_ciph" test failing) osmo-pcu: - mips (https://buildd.debian.org/status/fetch.php?pkg=osmo-pcu&arch=mips&ver=0.5.1…) (error: #error "Only little endian headers are supported yet. TODO: add missing structs") - s390x (https://buildd.debian.org/status/fetch.php?pkg=osmo-pcu&arch=s390x&ver=0.5.…) (error: #error "Only little endian headers are supported yet. TODO: add missing structs") Maybe some of you can immediately see what is wrong, and what needs to be fixed? Best regards Ruben

5 16

Femto Access Point provisioning for Osmocom/Sysmocom
by Mykola Shchetinin 19 Nov '18

19 Nov '18

Hello, dear Osmocom Community and Sysmocom Team! We are trying out Osmocom software (3G only) to replace the proprietary software that we are using now. And we like it very much :) Our femtocells were provisioned with the same proprietary software we used but now we have to do that ourselves when using Osmocom software. We have come up with a solution which we wish to share with you and hope it will come in handy. Also, I am curious about how you handle it. How do you provision femtocells you have? We've found this page: https://osmocom.org/projects/cellular-infrastructure/wiki/Configuring_the_i… But we were unable to follow the procedures described there as they are outdated (to be precise, they are for outdated firmware). We use ip.access nano3g femtocells (S8 and S16) which are provisioned by means of CWMP server (also called ACS - auto configuration server). (more info: https://en.wikipedia.org/wiki/TR-069) The network configuration and an address of ACS for a femtocell to use are configured through the web page after a factory reset of a femtocell. We looked at FreeACS at first (https://github.com/freeacs/freeacs). It looked quite dead half year ago, but it seems that it is being revived. Then we looked at GenieACS (https://github.com/genieacs/genieacs) and managed to make it provision the femtocell. I did get all CWMP params from the femtocell first by sending appropriate CWMP messages (getParameterNames, getParameterValues) to the FAP from the ACS and recording traffic with tcpdump. From the information I got, I made a configuration file where I changed some parameters like PLMNID or NTP server addresses to desired values. Then I wrote a script which read the configuration file and set the params of the femtocell using functions provided by GenieACS. I configured the GenieACS to execute the script when getting a request from femtocell. The sample configuration file and sample scripts are described in a document-reminder I wrote for myself: https://gist.github.com/efistokl/b95538772e54e5edb7765021c2b5a745#22-config… I didn't make it use different configurations for different femtocells yet. I just made it to allow me to work with Osmocom software and my femtocell. I wish to improve the usability of this by writing some cli program to make the configuration process of the femtocell more automated as we will need to provision multiple femtocells connected to a single Osmocom system and a single ACS later. (or change the ACS choice completely) Thank You for creating and maintaining such a cool software! Kind regards, Mykola Shchetinin P.S. Does anybody have experience using some other ACS/CWMP solution? Could you share it?

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2018