Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092022-11-16T13:46:32ZOpen Source Mobile Communications
Redmine OsmoGGSN (former OpenGGSN) - Bug #5773 (New): OsmoGGSN sends Direct Tunnel packets to the wrong I...https://projects.osmocom.org/issues/57732022-11-16T13:46:32Zmanatails
<p>When GTP-U Direct Tunnel is used, GGSN shall send all data packets to the RNC.</p>
<p>But sometimes when data packets are queued right after the Echo Request message from the SGSN, data packets are sent to the SGSN instead of RNC, causing SGSN to crash.</p>
<p>Attached is a pcap of the bug.</p>
<p>Packet no. 1-6 are correctly sent to the RNC at 10.27.30.100<br />But after packet no. 18 Echo response subsequent GTP-U packets are wrongly sent to the SGSN at 10.27.30.99 and SGSN reports Error indication.</p> OsmoSGSN - Bug #4886 (New): UE does not connect data when moving from 2G->3Ghttps://projects.osmocom.org/issues/48862020-12-02T12:46:39Zmanatails
<p>I am using separate MSC and SGSN for each RAN, osmo-sgsn handles UTRAN->GERAN switching just fine, sending not attached command and causing the phone to reattach.<br />But when phones move from GERAN to UTRAN only some phones connect to the data network properly, while some are stuck in Activate PDP Context requests</p> OsmoBSC - Bug #4884 (New): RLL_REL_IND is recieved after RF_CHAN_RELhttps://projects.osmocom.org/issues/48842020-12-02T01:55:42Zmanatails
<p>For some reason current version of osmo-bsc keeps getting RLL_REL_IND message after rf channel release when servicing nanoBTS, causing calls to fail a few seconds after connection.</p> OsmoMSC - Bug #4017 (New): MSC fails to handle callshttps://projects.osmocom.org/issues/40172019-05-22T03:26:31Zmanatails
<p>Osmo-MSC fails to handle calls sometimes after the phone has been registered to the network.</p>
<p>The following is the log from osmo-msc<br /><pre>
Wed May 22 12:17:58 2019 DVLR <000e> vlr_access_req_fsm.c:374 Process_Access_Request_VLR(TMSI-0x35814F56:UTRAN-Iu-158:CM_SERVICE_REQ)[0x1377b80]{PR_ARQ_S_INIT}: Another proc_arq_fsm is already associated with subscr IMSI-450091000000001:MSISDN-01000000001:TMSI-0x35814F56, terminating the other FSM.
Wed May 22 12:17:58 2019 DVLR <000e> vlr_access_req_fsm.c:103 Process_Access_Request_VLR(IMSI-450091000000001:MSISDN-01000000001:TMSI-0x35814F56:UTRAN-Iu-157:CM_SERVICE_REQ)[0x136efe0]{PR_ARQ_S_DONE}: transition to state PR_ARQ_S_DONE not permitted!
Wed May 22 12:17:58 2019 DIUCS <000f> msub.c:360 msc_a(TMSI-0x35814F56:UTRAN-Iu-158:CM_SERVICE_REQ)[0x13793b0]{MSC_A_ST_VALIDATE_L3}: Cannot associate with VLR subscr, another connection is already active at IMSI-450091000000001:MSISDN-01000000001:TMSI-0x35814F56:UTRAN-Iu-157:CM_SERVICE_REQ
Wed May 22 12:17:58 2019 DIUCS <000f> msub.c:362 msc_a(IMSI-450091000000001:MSISDN-01000000001:TMSI-0x35814F56:UTRAN-Iu-157:CM_SERVICE_REQ)[0x136ed80]{MSC_A_ST_COMMUNICATING}: Attempt to associate a second subscriber connection at TMSI-0x35814F56:UTRAN-Iu-158:CM_SERVICE_REQ
Wed May 22 12:17:58 2019 DIUCS <000f> gsm_04_08.c:805 msc_a(TMSI-0x35814F56:UTRAN-Iu-158:CM_SERVICE_REQ)[0x13793b0]{MSC_A_ST_RELEASING}: subscriber not allowed to do a CM Service Request
Wed May 22 12:17:58 2019 DIUCS <000f> msc_a.c:1525 msc_a(TMSI-0x35814F56:UTRAN-Iu-158:CM_SERVICE_REQ)[0x13793b0]{MSC_A_ST_RELEASING}: RAN decode error (rc=-5) for COMPL_L3 from MSC-I
Wed May 22 12:17:58 2019 DIUCS <000f> msc_a.c:1377 msc_a(IMSI-450091000000001:MSISDN-01000000001:TMSI-0x35814F56:UTRAN-Iu-157:CM_SERVICE_REQ)[0x136ed80]{MSC_A_ST_COMMUNICATING}: Received Clear Complete event, but did not send Clear Command
Wed May 22 12:18:01 2019 DVLR <000e> vlr_access_req_fsm.c:374 Process_Access_Request_VLR(TMSI-0x35814F56:UTRAN-Iu-159:CM_SERVICE_REQ)[0x1377d70]{PR_ARQ_S_INIT}: Another proc_arq_fsm is already associated with subscr IMSI-450091000000001:MSISDN-01000000001:TMSI-0x35814F56, terminating the other FSM.
Wed May 22 12:18:01 2019 DVLR <000e> vlr_access_req_fsm.c:103 Process_Access_Request_VLR(TMSI-0x35814F56:UTRAN-Iu-158:CM_SERVICE_REQ)[0x1377b80]{PR_ARQ_S_DONE}: transition to state PR_ARQ_S_DONE not permitted!
Wed May 22 12:18:02 2019 DIUCS <000f> ran_msg_iu.c:179 msc_i(IMSI-450091000000001:MSISDN-01000000001:TMSI-0x35814F56:UTRAN-Iu-159:CM_SERVICE_REQ)[0x136bce0]{READY}: RAN decode: RANAP: RAB Assignment Response does not contain RAB information
Wed May 22 12:18:02 2019 DIUCS <000f> ran_msg_iu.c:179 msc_a(IMSI-450091000000001:MSISDN-01000000001:TMSI-0x35814F56:UTRAN-Iu-159:CM_SERVICE_REQ)[0x136af60]{MSC_A_ST_COMMUNICATING}: RAN decode: RANAP: RAB Assignment Response does not contain RAB information
Wed May 22 12:18:02 2019 DIUCS <000f> msc_a.c:1285 msc_a(IMSI-450091000000001:MSISDN-01000000001:TMSI-0x35814F56:UTRAN-Iu-159:CM_SERVICE_REQ)[0x136af60]{MSC_A_ST_COMMUNICATING}: Assignment Failure, releasing call
Wed May 22 12:18:02 2019 DIUCS <000f> msc_a.c:1193 msc_a(IMSI-450091000000001:MSISDN-01000000001:TMSI-0x35814F56:UTRAN-Iu-159:CM_SERVICE_REQ)[0x136af60]{MSC_A_ST_RELEASING}: Message not permitted for initial conn: GSM48_MT_CC_RELEASE_COMPL
Wed May 22 12:18:02 2019 DIUCS <000f> msc_a.c:1525 msc_a(IMSI-450091000000001:MSISDN-01000000001:TMSI-0x35814F56:UTRAN-Iu-159:CM_SERVICE_REQ)[0x136af60]{MSC_A_ST_RELEASING}: RAN decode error (rc=-13) for DTAP from MSC-I
Wed May 22 12:18:06 2019 DIUCS <000f> ran_msg_iu.c:179 msc_i(IMSI-450091000000001:MSISDN-01000000001:TMSI-0x35814F56:UTRAN-Iu-160:CM_SERVICE_REQ)[0x1378ec0]{READY}: RAN decode: RANAP: RAB Assignment Response does not contain RAB information
Wed May 22 12:18:06 2019 DIUCS <000f> ran_msg_iu.c:179 msc_a(IMSI-450091000000001:MSISDN-01000000001:TMSI-0x35814F56:UTRAN-Iu-160:CM_SERVICE_REQ)[0x136af60]{MSC_A_ST_COMMUNICATING}: RAN decode: RANAP: RAB Assignment Response does not contain RAB information
Wed May 22 12:18:06 2019 DIUCS <000f> msc_a.c:1285 msc_a(IMSI-450091000000001:MSISDN-01000000001:TMSI-0x35814F56:UTRAN-Iu-160:CM_SERVICE_REQ)[0x136af60]{MSC_A_ST_COMMUNICATING}: Assignment Failure, releasing call
Wed May 22 12:18:28 2019 DIUCS <000f> msc_a.c:688 msc_a(TMSI-0x35814F56:UTRAN-Iu-158:CM_SERVICE_REQ)[0x13793b0]{MSC_A_ST_RELEASING}: Timeout while releasing, discarding right now
Wed May 22 12:18:28 2019 DLSCCP <0020> sccp_scoc.c:1677 SCCP-SCOC(158)[0x1370e70]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
</pre></p>
<p>osmo-sip-connector<br /><pre>
Wed May 22 12:18:02 2019 DMNCC <0001> mncc.c:76 Wanted rsp(MNCC_RTP_CREATE) but got(MNCC_REL_CNF) for leg(2147483705)
Wed May 22 12:18:06 2019 DMNCC <0001> mncc.c:76 Wanted rsp(MNCC_RTP_CREATE) but got(MNCC_REL_CNF) for leg(2147483706)
</pre></p> OsmoGGSN (former OpenGGSN) - Bug #3997 (Resolved): Retransmit queue is not clearedhttps://projects.osmocom.org/issues/39972019-05-11T10:07:22Zmanatails
<p>osmo-ggsn slowly fills its retransmit queue every few minutes, but queued items are not removed.</p>
<p>following is the view of the queue with QUEUE_DEBUG 1.</p>
<pre>
53 1 61635 54 52 1557380751 0
54 1 61636 55 53 1557380760 0
55 1 61637 56 54 1557380777 0
56 1 61638 57 55 1557380787 0
57 1 61639 58 56 1557380830 0
58 1 61640 59 57 1557380906 0
59 1 61641 60 58 1557381026 0
60 1 61642 61 59 1557381074 0
61 1 61643 62 60 1557381086 0
62 1 61644 63 61 1557381153 0
63 1 61645 64 62 1557381300 0
64 1 61646 65 63 1557381305 0
65 1 61647 66 64 1557381564 0
66 1 61648 67 65 1557381619 0
67 1 61649 68 66 1557381630 0
68 1 61650 69 67 1557381668 0
69 1 61651 70 68 1557381704 0
70 1 61652 71 69 1557381732 0
71 1 61653 72 70 1557381737 0
72 1 61654 73 71 1557381742 0
73 1 61655 74 72 1557381747 0
74 1 61656 75 73 1557381752 0
75 1 61657 76 74 1557381757 0
76 1 61658 77 75 1557381784 0
77 1 61659 78 76 1557381988 0
78 1 61660 79 77 1557382047 0
79 1 61661 80 78 1557382230 0
</pre> OsmoSGSN - Bug #3969 (Closed): Fix sgsn_ranap_iu_event() returning error on SECURITY_MODE_COMPLETEhttps://projects.osmocom.org/issues/39692019-05-03T00:55:37Zmanatails
<p>sgsn_ranap_iu_event() is returning an erroneous value even when the command is processed properly. Fixed to remove unnecessary cn_ranap_handle_co error messages.</p> OsmoSGSN - Bug #3727 (Resolved): SGSN segfaults on network type changehttps://projects.osmocom.org/issues/37272018-12-12T23:29:06Zmanatails
<p>When the phone changes its network type between GSM and UMTS osmo-sgsn crashes with the following log:</p>
<p><0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x760d06 CMD=UI DATA<br /><0002> gprs_gmm.c:1609 -> GMM RA UPDATE REQUEST type="RA updating" <br /><0002> gprs_gmm.c:1685 <abbr title="450091417013617/f99cab1e">MM</abbr> Looked up by matching TLLI and P_TMSI. BSSGP TLLI: b99cab1e, P-TMSI: f99cab1e (00000000), TLLI: 00000000 (00000000), RA: 450-09-1-1</p>
<p>Program received signal SIGSEGV, Segmentation fault.<br />0x0000000000409667 in gsm48_gmm_authorize (ctx=0x758600) at gprs_gmm.c:1051<br />1051 if (ctx->ran_type == MM_CTX_T_UTRAN_Iu && !ctx->iu.ue_ctx->integrity_active) {<br />(gdb)</p> osmo-sip-connector - Bug #3724 (New): Wrong media format used in SIP INVITE causes one-way audiohttps://projects.osmocom.org/issues/37242018-12-11T14:57:28Zmanatails
<p>osmo-sip-connector from the latest git repository specifies wrong audio codec in SIP INVITE message.</p>
<p>When using osmo-sip-connector to bridge a nanoBTS and an asterisk server, osmo-sip-connector sends 0 as the media codec which corresponds to G.711 PCMU, causing asterisk to respond in g711 and nanoBTS is unable to parse it.</p>
<p>Attached is a packet capture between the BSC and Asterisk server.</p> OsmoBSC - Bug #3707 (Closed): nanoBTS fails to starthttps://projects.osmocom.org/issues/37072018-11-26T13:05:17Zmanatails
<p>With the newest git repo version of osmo-bsc, my nanoBTS fails to start.</p>
<p>I can confirm that it works normally with ip.access softBSC and it used to work with osmo-nitb.</p>
<p>I thought osmocom Redmine issue <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: OsmoBSC + nanoBTS 165AU (DCS1800): smartphone Samsung 4mini 5 unable to register (it can on osmo-... (Resolved)" href="https://projects.osmocom.org/issues/3063">#3063</a> might be relevant and tried<br />setting/unsetting force-combined-si but I am still getting the same<br />result.<br />Attached are the packet capture and bsc config file, and debug log from osmo-bsc</p> OsmoSGSN - Bug #3696 (New): Intermittent Connection Drophttps://projects.osmocom.org/issues/36962018-11-15T00:37:56Zmanatails
<p>I've set up a mini 3G RAN with the newest git repo.</p>
<p>The phone works fine and successfully creates a PDP context, but data<br />only works for a few minutes before it stops.</p>
<p>Tested with a Samsung Galaxy S8 and an iPhone SE</p>