OpenBSC November 2018

openbsc@lists.osmocom.org

23 participants
30 discussions

by Pierre Kim

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.

6 years, 9 months

GSUP protocol manual in HLR, MSC, SGSN

by Neels Hofmeyr

(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

6 years, 9 months

3G data connection loss

by Pierre Kim

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

6 years, 9 months

Help with silent call

by Snehasish Kar

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

6 years, 9 months

Failing test cases (and builds) on other architectures in Debian

by Ruben Undheim

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

6 years, 9 months

Femto Access Point provisioning for Osmocom/Sysmocom

by Mykola Shchetinin

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?

6 years, 9 months

GSN Error Indication behavior

by Pierre Kim

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

6 years, 9 months

handover request

by Max

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

6 years, 9 months

ttcn3 question

by Neels Hofmeyr

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

6 years, 9 months

ipaccess-proxy usage help

by Mihai Ordean

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

6 years, 9 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2018