Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092019-09-12T14:07:31ZOpen Source Mobile Communications
Redmine OsmoMSC - Feature #4200 (In Progress): Work around nano3G-S16 requiring RAB ID to be below 16https://osmocom.org/issues/42002019-09-12T14:07:31Zefistokl
<p>Hardware: ip.access nano3g S16.</p>
<p>Tested against osmo-msc version branches 35c3 and cccamp19 (with Message Class and RAT GSUP IEs stripped out). Reproduced 3 times.</p>
<p>In the trace there are 17 incoming SIP calls. The last 2 failed (around packet 36826 and 37625). In the RAB-AssignmentResponse's for them I see "radioNetwork: failure-in-the-radio-interface-procedure (14)".</p>
<p>If I restart the osmo-msc, I can make another 15 calls.</p>
<p>IPs:<br />10.0.2.247 - nano3g S16<br />10.0.2.244 - RNC:<br /> - 10.0.2.244:5060 osmo-sip-connector<br /> - 10.0.2.244:5064 local PBX (kamailio)<br />172.48.2.1 - Remote PBX (kamailio)<br />172.48.1.5 - GSUP server</p>
<p>Note:<br />Apart from the osmocom software there is Kamailio and rtpengine installed alongside osmo-sip-connector to allow for transcoding. I've set it in a way so that it "sleeps" for 3 seconds before passing SIP INVITE to osmo-sip-connector. (If I don't do this then the UE will not respond to Paging Request (assuming it doesn't have enough time after Iu-Release which happens after USSD))</p> OsmoSGSN - Bug #4000 (Closed): Unknown PDP context after Iu-Release (and updated gtp-u endpoints)...https://osmocom.org/issues/40002019-05-14T11:36:08Zefistokl
<p>The bug seems to be triggered when the Iu-Release is performed, the GTP-U endpoints are updated (with Update PDP Context Request), and when the GTP-U packet arrives from GGSN to SGSN, then PDP context for given TEID is not found and then it is hard-dropped because of the error in gtp.c:</p>
<pre>
May 07 15:16:17 Core osmo-sgsn[4054]: <0023> gtp.c:2378 Packet from 10.0.1.123:2123, length: 55 content: 32 13 00 2f 00 00 00 01 98 1d 00 00 01 80 10 00 00 00 01 7f 0b 56 70 83 85 00 04 0a 00 01 7b 85 00 04 c0 a8 0e 10 87 00 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : Missing information field
May 07 15:16:17 Core osmo-sgsn[4054]: <000e> sgsn_libgtp.c:644 libgtp cb_conf(type=18, cause=-1, pdp=0x7f6447263060, cbp=0xc0eae0)
May 07 15:16:17 Core osmo-sgsn[4054]: <000e> sgsn_libgtp.c:648 libgtp EOF (type=18, pdp=0x7f6447263060, cbp=0xc0eae0)
May 07 15:16:17 Core osmo-sgsn[4054]: <0023> gtp.c:2800 Packet from 192.168.14.16:2152, length: 60 content: 30 ff 00 34 00 00 00 09 45 00 00 34 0a 29 00 00 f4 06 dc 57 45 ad 90 95 0a 00 00 01 01 bb ce 32 f1 00 89 77 34 68 f8 fa 80 11 0e 24 24 bd 00 00 01 01 08 0a c3 05 ef 21 00 05 39 a2 : Unknown PDP context, GTPv1
May 07 15:16:17 Core osmo-sgsn[4054]: <000e> sgsn_libgtp.c:669 PDP(248010132392306:5): Context 0x7f6447263060 was deleted
May 07 15:16:17 Core osmo-sgsn[4054]: <000e> gprs_sgsn.c:740 PDP(248010132392306/0) Hard-dropping PDP ctx due to GGSN recovery
May 07 15:16:17 Core osmo-sgsn[4054]: <0023> pdp.c:255 Begin pdp_tiddel tid = 5603293231010842
May 07 15:16:17 Core osmo-sgsn[4054]: <0023> pdp.c:262 End pdp_tiddel: PDP found
</pre>
<p>The relevant PCAP and logs are attached.<br />10.0.2.52 - Femtocell<br />10.0.2.51 - SGSN<br />10.0.1.123 or 192.168.14.16 - GGSN</p>
<p>I use a filthy hack which is to comment out the call to <code class="c syntaxhl"><span class="n">mmctx_change_gtpu_endpoints_to_sgsn</span></code> function in sgsn.</p>
<p>Btw, possibly bug in the gtp library...</p> OsmoSGSN - Support #3920 (In Progress): PCAPs files of 3G PS for Osmocom network and Commercial onehttps://osmocom.org/issues/39202019-04-12T12:51:19Zefistokl
<p>In iphone-6s-q.pcap - commercial software, trace taken on 10.0.2.195:<br />(around between 10:22:44 and 10:23:17 I didn't have internet, maybe temporary fail of the system to respond to the packet 10754. All other time the data was working)<br />10.0.2.199 - nano3g ip.access S8<br />10.0.2.195 - (not osmocom) core network (without HLR and GGSN)<br />10.0.1.123 or 192.168.14.16 (same host) - GGSN and HLR</p>
<p>In iphone-6s-osmocom.pcap - osmocom based system. Data stopped working around 10:05:59 (time in the trace, or packet 3727), trace taken on 10.0.2.51:<br />10.0.2.52 - nano3g ip.access S8<br />10.0.2.51 - osmocom host (without HLR and GGSN)<br />10.0.1.123 or 192.168.14.16 (same host) - GGSN<br />172.48.1.5 - HLR</p>
<p>At first glance it seems that Osmo-SGSN doesn't respond properly to (GMM) Service Requests which come some time after initial PS activation. I haven't inspected the traces thoroughly yet.</p> OsmoSGSN - Bug #3908 (Resolved): "PS Activation" takes long time - missing Iu-Release Command aft...https://osmocom.org/issues/39082019-04-07T13:39:06Zefistokl
<p>I've noticed that it takes around 10 seconds for PS to work after a phone becomes registered on the network. Basically, the phone waited for 10 seconds after Attach Complete message and then sent Iu-ReleaseRequest and only then Service Request. (after Iu-Release completion)</p>
<p>If I send the Iu-ReleaseCommand (diff file sgsn-iu-release-after-attach-complete.diff, applied to 1.4.0) upon receiving Attach Complete message then the phone sends Service Request right away after Iu-Release completion.</p>
<p>RANAP trace without the fix - without-fix.pcap (Attach Complete - packet # 73 - there you see around 10s delay betweenand the phone sending Iu-ReleaseRequest)<br />RANAP trace with the fix - with-fix.pcap (Attach Complete - packet # 43)</p> OsmoMSC - Bug #3880 (New): GSUP MT-ForwardSM Message Reference - wrong value in a responsehttps://osmocom.org/issues/38802019-04-01T07:47:57Zefistokl
<p>The Message Reference that comes in GSUP message is not used and the GSUP response for the SMS contains the wrong Message Reference which is assigned by MSC, hence the HLR/SMSC (or whatever on the other side of the GSUP connection is) isn't able to correlate the request and the response.</p>