November 2018 - OpenBSC - lists.osmocom.org

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

19 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

GSN Error Indication behavior
by Pierre Kim 12 Nov '18

12 Nov '18

After some debugging I found that the intermittent data loss was caused by the GSN not properly reacting to Error Indication packets. >From GGSN: <0002> ggsn.c:809 PDP(450091417013617:5): Packet received on APN(internet): forwarding to tun apn0 <000d> gtp.c:2681 Packet from 192.168.27.49:2152, length: 24 content: 32 1a 00 10 00 00 00 00 40 8e 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> pdp.c:255 Begin pdp_tiddel tid = 5716310714190054 <000d> pdp.c:262 End pdp_tiddel: PDP found When the GGSN receives an error indication, isnt' it supposed to acknowlege the SGSN and attempt to reinitialize the connection? In my case the GGSN simply deleted the PDP context locally and both SGSN and GGSN gets flooded by unknown PDP context error, while the phone keeps trying to transmit data. Tested on lastest git version and lastest release version: osmo-sgsn 1.3.0, osmo-ggsn 1.2.1 Regards, Pierre

3 3

handover request
by Max 09 Nov '18

09 Nov '18

Hi. I've noticed that we don't have any code (besides basic definition) for handover request message (BSS_MAP_MSG_HANDOVER_RQST) from 48.008 3.2.1.8 in libosmocore or osmo-*sc. Is it because it's in some patch hanging somewhere in gerrit or we don't need it (yet)? -- - 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 Directors: Harald Welte

2 2

ttcn3 question
by Neels Hofmeyr 08 Nov '18

08 Nov '18

I guess I'm again hitting the same ttcn3 wall that has caused me trouble countless times before... I'm trying to run the already existing TC_ho_into_this_bsc(), but before it starts I want to occupy all lchans. This is the working TC_ho_into_this_bsc(): testcase TC_ho_into_this_bsc() runs on test_CT { var MSC_ConnHdlr vc_conn; var TestHdlrParams pars := f_gen_test_hdlr_pars(); f_init(1, true); f_sleep(1.0); pars.handover.sccp_addr_msc := g_bssap.sccp_addr_own; pars.handover.sccp_addr_bsc := g_bssap.sccp_addr_peer; vc_conn := f_start_handler(refers(f_tc_ho_into_this_bsc), pars); vc_conn.done; } I just want to insert a bit of TC_chan_exhaustion() like so: testcase TC_ho_in_fail_no_chan() runs on test_CT { var integer i; var MSC_ConnHdlr vc_conn; var TestHdlrParams pars := f_gen_test_hdlr_pars(); f_init(1, true); f_sleep(1.0); /* occupy all lchans */ for (i := 0; i < NUM_TCHF_PER_BTS + NUM_TCHH_PER_BTS + NUM_SDCCH_PER_BTS; i := i+1) { var RslChannelNr chan_nr := f_chreq_act_ack('23'O, i); } pars.handover.sccp_addr_msc := g_bssap.sccp_addr_own; pars.handover.sccp_addr_bsc := g_bssap.sccp_addr_peer; vc_conn := f_start_handler(refers(f_tc_ho_in_fail_no_chan), pars); vc_conn.done; } But no matter which way I turn it, ttcn3 does not agree. * I either get: 21:36:03.008137 mtc BSC_Tests.ttcn:1553 Dynamic test case error: Using the value of an unbound component reference. 21:36:03.008163 mtc BSC_Tests.ttcn:1553 setverdict(error): none -> error This is during f_connect_handler(): connect(vc_conn:BSSMAPEM, g_bssap.vc_BSSMAP:PROC); with the log revealing [1] below * Or I get: 21:31:45.678006 mtc BSC_Tests.ttcn:366 Dynamic test case error: Port IPA_RSL[0] has neither connections nor mappings. Message cannot be sent on it. 21:31:45.678094 mtc BSC_Tests.ttcn:366 setverdict(error): none -> error This stuff really gets me steaming with ttcn... anyhow... I'm fairly certain it has to do with the 'true' arg of f_init() starting the RSL emulation, so I need to re-invent TC_chan_exhaustion() on the MSC_ConnHdlr? Sort of like the hack I have in f_tc_ho_into_this_bsc()? " /* Hack: the proper way would be to wait for the BSSMAP Handover Request ACK and extract the * actual assigned chan_nr from its L3 (RR Handover Command) message. But osmo-bsc starts acting * on the lchan even before we get a chance to evaluate the BSSMAP Handover Request ACK. So we * need to assume that osmo-bsc will activate TS 1 and already set up this lchan's RSL emulation * before we get started. */ var RslChannelNr new_chan_nr := valueof(t_RslChanNr0(1, RSL_CHAN_NR_Bm_ACCH)); f_rslem_register(0, new_chan_nr); g_chan_nr := new_chan_nr; f_sleep(1.0); " I wish it were easier...? ~N [1] 21:36:03.008009 mtc BSC_Tests.ttcn:1552 XXXXX { vc_M3UA := VirtMSC-M3UA(4), vc_IPA := <unbound>, vc_WAIT := <unbound>, vc_SCCP := VirtMSC-SCCP(3), sccp_pars := { sio := { ni := '10'B, prio := '00'B, si := '0011'B }, opc := 185, dpc := 187, sls := 0, sccp_serviceType := "mtp3_itu", ssn := 254 }, sccp_addr_own := { addressIndicator := { pointCodeIndic := '1'B, ssnIndicator := '1'B, globalTitleIndic := '0000'B, routingIndicator := '1'B }, signPointCode := '00000010111001'B, subsystemNumber := 254, globalTitle := omit }, sccp_addr_peer := { addressIndicator := { pointCodeIndic := '1'B, ssnIndicator := '1'B, globalTitleIndic := '0000'B, routingIndicator := '1'B }, signPointCode := '00000010111011'B, subsystemNumber := 254, globalTitle := omit }, vc_BSSMAP := <unbound> } -- - 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

1 0

ipaccess-proxy usage help
by Mihai Ordean 08 Nov '18

08 Nov '18

Hey guys, Sorry to keep insisting on this, but I don't seem to be able to make ipaccess-proxy work with either the old OpenBTS nor with the new Osmocom stack. Did anyone have any recent(ish) experience using it. At this point I'd appreciate any tip anyone can provide towards getting a working setup. Thanks, -- Mihai

1 0

OC-2G merge to osmo-bts
by Harald Welte 08 Nov '18

08 Nov '18

Dear Osmocom team, Omar has thankfully submitted patches for inclusion of OC-2G support to gerrit, see https://gerrit.osmocom.org/#/c/osmo-bts/+/11447/ for the bulk of the code. An initial review showed there are *many* parts that are identical to osmo-bts-litecell15, and we generally don't like "copy+paste" programming. In the end we have multiple compies of essentially the same source files, becoming a maintenance problem over time, when fixes are applied to one copy, but not the other. I've manually looked through each of the files and looked at the differences between the oc2g and the lc15 counterpart. == 100% identical to osmo-bts-sysmo or osmo-bts-lc15: oml_router.c oml_router.h misc/oc2gbts_nl.c == 99% identical to lc15 (just names changed) hw_misc.h hw_misc.c l1_transp.h l1_trans_hw.c oc2gbts.c / lc15bts.c oc2gbts_vty.c / lc15bts_vty.c oml.c tch.c utils.c utils.h l1_if.h misc/oc2gbts_bts.h misc/oc2gbts_bid.h misc/oc2gbts_clock.h misc/oc2gbts_clock.c misc/oc2gbts_led.c misc/oc2gbts_swd.c misc/oc2gbts_swd.h == 80% identical to lc15 (some small changes) l1_if.c misc/oc2gbts_bts.c misc/oc2gbts_mgr.c misc/oc2gbts_mgr.h misc/oc2gbts_mgr_nl.c misc/oc2gbts_temp.c misc/oc2gbts_temp.h == more differences compared to lc15, possibly not intentional? / what to do? misc/oc2gbts_temp.c misc/oc2gbts_mgr_vty.c misc/oc2gbts_misc.c misc/oc2gbts_par.c misc/oc2gbts_power.c misc/oc2gbts_util.c So we have to discuss how to go about this. The 100% identical files are easy, one can simply lik the existing implementation. We could also introduce a "src/nuran-common" directory for common code between the different models. For those parts with less similarity, this may require some refactoring, so that common/shared code goes to common/shared files and really only those bits that differ are handled in the respective implementations. Given that osmo-bts-litecell15 also started as copy of osmo-bts-sysmo, there may be room for further unification, but let's not conflate those two discussions. In terms of process, * we could first merge all the copies and then further unify the code, or * we could first modify the existing core/lc15 code to be able to merge OC2G coe without introducing lots of copied code. Any comments/suggestions/ideas? 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)

3 5