Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-26T14:00:15ZOpen Source Mobile Communications
Redmine OsmoMGW - Bug #6424 (In Progress): TC_one_crcx_loopback_rtp_implicit consistently failing in mast...https://osmocom.org/issues/64242024-03-26T14:00:15Zlaforge
<p>`TC_one_crcx_loopback_rtp_implicit` appears to be failing consistently in master for 30+ consecutive builds. Meanwhile, the same test is passing just fine in latest. So there seems to be some (long-standing) regression in master?</p> Osmo-CC - Feature #6319 (New): protocol version should have a defined end markerhttps://osmocom.org/issues/63192023-12-25T00:38:03Zneelsnhofmeyr@sysmocom.de
<p>in osmo-cc-v0.91.pdf I read:</p>
<pre>When a connection is established, both ends send a version string of eight bytes:
“OSMOCCv1” first. (no \0 termination, no line feed, case sensitive) The Version number is
defined by the eighth byte. In this case the protocol version is ‘1’.</pre>
<p>I think it would be better to make this more flexible than a single version char.</p>
<p>I was thinking, what happens when we reach "OSMOCCv10"? It cannot be distinguished from "OSMOCCv1" followed by an unrelated "0".</p>
<p>So I guess it should actually be \0 terminated, or it should be in a TLV, or it should be defined that the version string is sent in a single TCP packet where the entire payload is just the version string? Something that allows extending the string in the future.</p>
<p>What do you think?</p> OsmoBSC - Bug #6318 (Feedback): Show lchan shows wrong number of channels for TCHhttps://osmocom.org/issues/63182023-12-23T15:14:50Zmatanp
<p>When configuring a channel is configured as TCH, `show lchan` show 3 lchans for that channel.</p>
<p>tested on commit 9baa065c8da5ecd96e9a2f2c6d5d1c57ece754b2, I will test it on the master soon</p> OsmoMSC - Bug #6217 (Feedback): Bearer Capability mismatch in MT SETUPhttps://osmocom.org/issues/62172023-10-10T13:13:58Zfixeria
<p>While investigating <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: mobile: MT calls not working anymore (Resolved)" href="https://osmocom.org/issues/6216">#6216</a>, I noticed that the Bearer Capability in MT SETUP looks weird and does not match such in the MO SETUP.</p>
<p>[frame 9] MO Setup (from SE K800):</p>
<pre>
Bearer Capability 1 - (MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1)
Element ID: 0x04
Length: 6
Octet 3
0... .... = Extension: Extended
.11. .... = Radio channel requirement: MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .000 = Information transfer capability: Speech (0x0)
Octets 3a - Speech Versions
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0100 = Speech version indication: GSM full rate speech version 3(FR AMR) (0x4)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0010 = Speech version indication: GSM full rate speech version 2(GSM EFR) (0x2)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0000 = Speech version indication: GSM full rate speech version 1(GSM FR) (0x0)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0101 = Speech version indication: GSM half rate speech version 3(HR AMR) (0x5)
1... .... = Extension: No Extension
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0001 = Speech version indication: GSM half rate speech version 1(GSM HR) (0x1)
</pre>
<p>[frame 22] MT Setup (from osmo-msc):</p>
<pre>
Bearer Capability 1 - (MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1)
Element ID: 0x04
Length: 5
Octet 3
0... .... = Extension: Extended
.11. .... = Radio channel requirement: MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .000 = Information transfer capability: Speech (0x0)
Octets 3a - Speech Versions
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0100 = Speech version indication: GSM full rate speech version 3(FR AMR) (0x4)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0101 = Speech version indication: GSM half rate speech version 3(HR AMR) (0x5)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 1011 = Speech version indication: GSM half rate speech version 6(OHR AMR) (0xb)
1... .... = Extension: No Extension
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0000 = Speech version indication: GSM full rate speech version 1(GSM FR) (0x0)
</pre>
<p>osmo-msc.git 1792ba92c1f939fb232e25ae1124eda7bb11983f (1.11.1)<br />libosmocore.git 435856be518c9d3531ae5b8cbadac1474d521f3a</p> Core testing infrastructure - Bug #6185 (New): Submit titan.ProtocolEmulations.SCCP patch upstreamhttps://osmocom.org/issues/61852023-09-20T11:38:25Zpespin
<p>It was noticed that we currently hold & use in osmo-ttcn3-hacks our own fork of titan.ProtocolEmulations.SCCP.git [1].</p>
<p>We use our own fork because we are using an extra patch on top of master [2]. AFAICT, that patch has never been submitted upstream, but at first glance it looks like it should?</p>
<p>The upstream to submit to is in gitlab [3].</p>
<p>[1] <a class="external" href="https://github.com/osmocom/titan.ProtocolEmulations.SCCP">https://github.com/osmocom/titan.ProtocolEmulations.SCCP</a><br />[2] <a class="external" href="https://github.com/osmocom/titan.ProtocolEmulations.SCCP/commit/17a894fc6620a0df11d0d98c897fb66168276b16">https://github.com/osmocom/titan.ProtocolEmulations.SCCP/commit/17a894fc6620a0df11d0d98c897fb66168276b16</a><br />[3] <a class="external" href="https://gitlab.eclipse.org/eclipse/titan/titan.ProtocolEmulations.SCCP">https://gitlab.eclipse.org/eclipse/titan/titan.ProtocolEmulations.SCCP</a></p> OsmoMSC - Feature #6151 (Feedback): osmo-msc: Ability to configure (VTY) the AMR(-WB) formats use...https://osmocom.org/issues/61512023-08-25T16:04:43Zpespin
<p>Right now, RAB-ASsignment-Req message is built in osmo-iuh.git and it is hardcoded to built an RFCI list basically containing AMR 12k2.</p>
<p>The interesting related code path is:<br /><pre>
ran_iu_encode(RAN_MSG_ASSIGNMENT_COMMAND)
ran_iu_make_rab_assignment
ranap_new_msg_rab_assign_voice [osmo-iuh]
new_rab_par_voice
new_sdu_par_item
</pre></p>
<p>If you check new_sdu_par_item() in osmo-iuh.git (<a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-iuh/src/branch/master/src/ranap_msg_factory.c#L556">https://gitea.osmocom.org/cellular-infrastructure/osmo-iuh/src/branch/master/src/ranap_msg_factory.c#L556</a>), you can see how the SDUs are added there, hardcoded.</p>
<p>Ideally, the RFCI list would be passed to ranap_new_msg_rab_assign_voice() from osmo-msc.</p>
<p>Then, from osmo-msc, an RFCI would be built based on:<br />- Whether the UE supports AMR or AMR-WB (CC Setup message, "Supported Codec List" IE)<br />- Whether osmo-msc is configured to serve AMR or/and AMR-WB on the VTY<br />- Whatever other restrictions on the other call leg</p>
<p>This would allow, for instance testing IuUP/AMR-WB calls.</p>
<p>If AMR-WB is selected, we probably need to update the SDP related paths to add "16000" after IUFP:<br /><pre>
a=rtpmap:97 VND.3GPP.IUFP/16000
</pre></p>
Some related specs:
<ul>
<li>3GPP TS 25.413 (RANAP)</li>
<li>3GPP TS 25.415 (IuUP)</li>
<li>3GPP TS 26.103 (Speech codec List for GERAN anf UMTS)</li>
<li>3GPP TS 26.171, 3GPP TS 26.201, 3GPP TS 26.202 (AMR-WB)</li>
<li>RFC 4867 (RTP for AMR, AMR-WB)</li>
</ul> OsmoHNBGW - Feature #6085 (New): context_map_sccp.c parrots states/events that the SCCP-SCOC FSM ...https://osmocom.org/issues/60852023-07-04T22:22:53Zneelsnhofmeyr@sysmocom.de
<p>When I implemented the SCCP handling FSM for osmo-hnbgw, I was thinking in lines of what events I expect to happen on the SCCP wire, and overlooked the handling that the libosmo-sigtran SCCP-SCOC FSM already provides.</p>
<p>For example, if we want to disconnect while still waiting for an SCCP CC, IIUC there is no need for the context_map_sccp FSM to wait for the CC first -- the SCCP-SCOC already does that.<br />We should just dispatch the DISCONN primitive e.g. via osmo_sccp_tx_disconn(), and SCCP-SCOC will wait for the CC and then RLSD under the hood, for free.</p>
<p>Likely there are more unnecessary dups of SCCP-SCOC features in that FSM.</p> OsmoHNBGW - Feature #6051 (New): misnomer in internal SCCP functionshttps://osmocom.org/issues/60512023-06-02T15:08:18Zneelsnhofmeyr@sysmocom.de
<p>code review has indicated that functions talking to the SCCP User SAP should not be named tx_foo().</p>
<p>See <br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-hnbgw/+/32915">https://gerrit.osmocom.org/c/osmo-hnbgw/+/32915</a><br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-hnbgw/+/33128">https://gerrit.osmocom.org/c/osmo-hnbgw/+/33128</a></p>
<p>It came up in code review for these patches, after the functions in question had already been merged by earlier patches.</p>
<p>List the functions that should be renamed,<br />and choose names that everyone agrees with.</p> OsmoBSC - Bug #5982 (Feedback): conn->fi is NULL in gscon_bssmap_clear()https://osmocom.org/issues/59822023-03-29T16:50:48Zkeith
<p>not master, but I don't think anything relevant has changed, there is one SEGV fix (7a0bef1ae4784203bf5f93b2dc2c4138dcad9397) but my quick static analysis suggests it's not related.</p>
<p>Program terminated with signal SIGSEGV, Segmentation fault.</p>
<pre>
(gdb) bt
#0 0x0000558c248184b4 in gscon_bssmap_clear (conn=conn@entry=0x558c262a0410, cause=cause@entry=GSM0808_CAUSE_EQUIPMENT_FAILURE) at bsc_subscr_conn_fsm.c:151
#1 0x0000558c24819932 in gscon_forget_lchan (conn=conn@entry=0x558c262a0410, lchan=lchan@entry=0x7faef1906718) at bsc_subscr_conn_fsm.c:943
#2 0x0000558c2487f3cf in lchan_fsm_wait_rf_release_ack_onenter (fi=<optimized out>, prev_state=<optimized out>) at lchan_fsm.c:1429
#3 0x00007faef078b41b in ?? () from /usr/lib/x86_64-linux-gnu/libosmocore.so.19
#4 0x00007faef078bb1d in _osmo_fsm_inst_state_chg () from /usr/lib/x86_64-linux-gnu/libosmocore.so.19
#5 0x0000558c24871c56 in lchan_fsm_timer_cb (fi=0x558c26255430) at lchan_fsm.c:1810
#6 0x00007faef078d0f1 in ?? () from /usr/lib/x86_64-linux-gnu/libosmocore.so.19
#7 0x00007faef07861f6 in osmo_timers_update () from /usr/lib/x86_64-linux-gnu/libosmocore.so.19
#8 0x00007faef0786d25 in ?? () from /usr/lib/x86_64-linux-gnu/libosmocore.so.19
#9 0x00007faef0786db6 in osmo_select_main_ctx () from /usr/lib/x86_64-linux-gnu/libosmocore.so.19
#10 0x0000558c247dc486 in main (argc=<optimized out>, argv=<optimized out>) at osmo_bsc_main.c:1031
(gdb) p conn->fi
$4 = (struct osmo_fsm_inst *) 0x0
</pre>
<p>I don't have log at level DEBUG but this looks to be the trigger condition:</p>
<pre><code>DRSL ERROR handover_fsm.c:1557 handover(intraBSC_msc0-conn1_subscr-IMSI-[redacted]-TMSI-0x213e241e)[0x558c262a2e70]{WAIT_LCHAN_ACTIVE}: (4-0-4-TCH_F-0-SPEECH_V1) --HO-> (0-0-4-TCH/F_TCH/H_SDCCH8_PDCH:PDCH-0) (subscr subscr-IMSI-[redacted]-TMSI-0x213e241e) HO-intraBSC: Handover failed in state WAIT_SCCP_RLSD, Connection released: Connection releasing in the middle of handover</code></pre>
<p>I have four SEGV in the log over the last few days and all are preceded by this RSL ERROR, however in at least one of the core dumps, conn->fi is not NULL but the crash is the same, weird?</p>
<p>coredumps are available. ping me on IRC for access.</p> libosmo-sccp + libosmo-sigtran - Feature #5917 (Feedback): immediately detect SCTP SHUTDOWN in SC...https://osmocom.org/issues/59172023-02-21T03:39:24Zneelsnhofmeyr@sysmocom.de
<p>This is a question about SCCP concepts for link loss detection.</p>
<p>I'm trying to trigger an SCCP link loss to examine the cleanup / leak behavior of osmo-hnbgw.<br />I'd like to find out how an SCTP link loss would propagate to osmo-hnbgw code and signal an SCCP link loss.<br />(IOW looking for a place that would trigger an FSM event like MY_SCCP_EV_LINK_LOST)</p>
<p>I have two scenarios, one that osmo-stp is killed, the other that the remote entity behind osmo-stp is disconnected.</p>
<hr />
<p>(1) kill osmo-stp</p>
I tried this:
<ul>
<li>in HNBGW_Tests.ttcn, cranked up T_guard to 10000.0 s</li>
<li>in a RAB Assignment test, just after the RAB is established, insert f_sleep(5000.0)</li>
<li>run the test to establish a context mapping with SCCP connection in osmo-hnbgw</li>
<li>kill osmo-stp</li>
</ul>
<p>I immediately see lots of low level DLINP, DLSS7 and some DLSCCP logging showing that an SCTP SHUTDOWN event was processed, and that the XUA AS restarts and tries to reconnect. But none of this makes its way up into osmo-hnbgw.</p>
<p>After about 15 minutes(!), I receive sccp_sap_up(N-DISCONNECT.indication) on the SCCP connection.<br />So, we do have a cleanup trigger, but</p>
<ul>
<li>Is it expected to take this long, given that an SCTP SHUTDOWN is detected in libosmo-sigtran immediately?</li>
<li>Do we only get an N-DISCONNECT on individual SCCP conns? My idea was to trigger a LINK_LOST event on the SCCP link to the CN, i.e. a signal that the entire SCCP layer is gone. Does that exist, conceptually?</li>
</ul>
<p>(log attached)</p>
<p>In contrast, when the RUA side of osmo-hnbgw sees an SCTP SHUTDOWN, osmo-hnbgw immediately registers that all HNB are disconnected, by means of the read cb() passed to osmo_stream_srv_create().</p>
<hr />
<p>(2) disconnect remote SCCP peer, STP still up<br />i.e. in ttcn, after the conn is established, call f_ran_adapter_cleanup(g_msc); f_ran_adapter_cleanup(g_sgsn);<br />and continue to f_sleep(5000.0) keeping the HNB connected.</p>
<p>Here I immediately see an N-PCSTATE.indication containing a DUNA (Destination Unavailable) coming up the SCCP user SAP, one each for the MSC and the SGSN point-code. osmo-hnbgw ignores N-PCSTATE so far, I guess it might be a good idea to implement acting on the DUNA messages. I see now that we can simply read out prim->u.pcstate.</p>
<p>Since the DUNA is so far ignored, the same as above happens. After about 15 minutes, sccp_scoc.c sends up an N-DISCONNECT for the individual SCCP connection and we do clean up, eventually.</p>
<hr />
So in summary:
<ul>
<li>when a remote entity behind STP goes bust, i can already now trigger my LINK_LOST event when osmo-hnbgw sees a PCSTATE indicating that the remote point-code for CS / PS CN becomes unavailable.</li>
<li>when the first SCTP hop goes bust (kill osmo-stp), maybe we can implement some prim going up the SCCP user SAP? Would that also be a DUNA, based on active SCCP conns' remote point-code, or is that a hacky layer violation?</li>
</ul> OsmoHNBGW - Feature #5904 (New): HNBAP Register Request handling does checks that seem to make no...https://osmocom.org/issues/59042023-02-11T02:28:42Zneelsnhofmeyr@sysmocom.de
<p>Looking at this code, a couple of things seem to make no sense:</p>
<p><a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-hnbgw/src/commit/a3c7f750a2f77c0c0e0ade1800f5b3a97a2f0b6e/src/osmo-hnbgw/hnbgw_hnbap.c#L431">https://gitea.osmocom.org/cellular-infrastructure/osmo-hnbgw/src/commit/a3c7f750a2f77c0c0e0ade1800f5b3a97a2f0b6e/src/osmo-hnbgw/hnbgw_hnbap.c#L431</a></p>
<ul>
<li>we are using getpeername() to compare the remote address of the current ctx to all other hnb. But we are handling a PDU in an accept()ed connection, and the hnb_context *ctx has already been looked up according to the remote address the PDU was received from.</li>
</ul>
<ul>
<li>assuming there are two connections from the same remote address, what do we care about the IP address? if there are two HNB entities connecting via two distinct conns, so be it, from the same address or not. We should only care about the HNB id (LAC,SAC,RAC,CID,MCC,MNC identity)</li>
</ul>
<ul>
<li>assuming we want to check the remote address: in the error checking path of failed getpeername(), we are still going on to compare as if the result from getpeername() was valid.</li>
</ul>
<ul>
<li>the loop is guarding against two HNB registering with identical HNB id.
<ul>
<li>When this occurs from the same remote address, we discard the <strong>old</strong> hnb_context. However, in practice it seems that instead of allocating another hnb_context on the same remote address, instead the HNB-Register-Req is dispatched to the same hnb_context in osmo-hnbgw, and this loop is essentially skipped (the log often shows the "(duplicated)" at the bottom of the function).</li>
<li>When this occurs from a different remote address, we reject the <strong>new</strong> hnb_context (bottom of the loop body). Now, in recent efforts to hunt down UE state leaks in osmo-hnbgw, it became clear that a HNB disconnecting may go unnoticed. Imagine a HNB's conn being disrupted, its state still present in osmo-hnbgw. If a new conn is established for this HNB from another remote address, we refuse this new connection, favoring the disrupted connection. It may be frustrating for a user trying to reconnect a HNB via a different link. The comment names two reasons:
<ul>
<li>misconfiguration: it is the user's responsibility to configure distinct HNBs with distinct identities. Is it helpful to refuse a new connection when a previous connection became stale and lingers? It may avoid oscillation of two HNBs with same id competing, but it is also hard to recover from a failed link when refusing new connections.</li>
<li>impersonation: we have no authentication of HNB, we are utterly incapable of avoiding impersonation anyway.</li>
</ul></li>
</ul></li>
</ul>
<p>3GPP TS 25.469 8.2.4 Abnormal Conditions:<br />""" <br />If the HNB-GW receives a duplicate HNB REGISTER REQUEST (i.e. for an already registered HNB identified by the<br />unique HNB identity), then the new HNB REGISTER REQUEST shall override the existing registration and the<br />handling of the new HNB REGISTER REQUEST is according to section 8.2.<br />"""</p>
Context:
<ul>
<li>this patch introduced the reject on duplicate HNB REGISTER REQ: <a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-iuh/commit/c964a2cfa1b08e5bbda5d721a7a0095d26b53791">https://gitea.osmocom.org/cellular-infrastructure/osmo-iuh/commit/c964a2cfa1b08e5bbda5d721a7a0095d26b53791</a></li>
<li>this patch introduced accepting the new HNB REGISTER REQ when from the same address: <a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-hnbgw/commit/12bc4afab3096c60554cd6d43fa11840bd76228c">https://gitea.osmocom.org/cellular-infrastructure/osmo-hnbgw/commit/12bc4afab3096c60554cd6d43fa11840bd76228c</a></li>
</ul>
<p>It seems the initial motion to reject a duplicate HNB REGISTER was wrong, and the newer patch tried to alleviate this, but still kept the rejection based on the remote address for reasons not named.</p>
My idea for this is:
<ul>
<li>do not check remote addresses at all.</li>
<li>compare only HNB IDs. If they match, always discard the <strong>old</strong> hnb_context, allow the new HNB register.</li>
</ul>
<p>To test this, I implemented this behavior, and HNBGW_Tests.ttcn3 still succeed<br />(with only the expected failure of TC_hnb_register_duplicate() that no longer gets the HNB Register Reject it wants to see)<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-hnbgw/+/31289">https://gerrit.osmocom.org/c/osmo-hnbgw/+/31289</a></p>
<p>feedback welcome</p> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://osmocom.org/issues/58952023-02-07T03:11:09Zkeith
<p>Writing this up now while it's a bit fresh...</p>
<p>I have spent the last 12 hours or so working with people on site to try to track down these problems:</p>
<p>Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)</p>
<p>Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.</p>
<p>However, today I discovered the extent of how bad this was on local MS to MS calls.</p>
<p>After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.</p>
<p>Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.</p>
<p>Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.</p>
<p>So what to do? Well note it at least. I don't have another lc15 to test on. <br />Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.</p>
<p>There's the chance that this was fixed since 1.4.0 or in another lib.</p>
<p><em>Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.</em></p> OsmoHNBGW - Bug #5876 (New): on HNBAP HNB Register, clear previous UE state if anyhttps://osmocom.org/issues/58762023-01-25T14:03:01Zneelsnhofmeyr@sysmocom.de
<p>when a HNB registers with osmo-hnbgw, and the same HNB is already registered, osmo-hnbgw keeps the HNB state and simply logs "(duplicated)" with the HNB Register Request log.</p>
<p>A HNB should only register when it has restarted, and no UE state should stay around when that happens.<br />So, upon HNB Register Request, if we find that HNB already connected, clear out any previous state on that HNB.</p>
<p>Otherwise we likely keep stale UE state and stale SCCP conns indefinitely, by ignoring a restart of a HNB.</p> OsmoHLR - Feature #5865 (New): Automate selection of LU Reject Causehttps://osmocom.org/issues/58652023-01-20T13:59:07Zkeith
<p>There is some suggestion in <a class="external" href="https://gerrit.osmocom.org/c/osmo-hlr/+/16808">https://gerrit.osmocom.org/c/osmo-hlr/+/16808</a> that osmo-hlr could use some criteria to decide what cause/reason to send to the GSUP client when rejecting a Location/Routing Update</p>
<p>Possibly, sending "IMSI Unknown in HLR" is wrong when the SIM is foreign to our network.</p>
<p>We could have a regex config option to let osmo-hlr know what is "our" SIM or not. Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP? I'm not familiar with GSUP.</p> Cellular Network Infrastructure - Feature #5771 (New): series of presentations about the invididu...https://osmocom.org/issues/57712022-11-14T19:25:57Zlaforge
<p>Most of the talks we ever gave on setting up and running the Osmocom CNI are ages old and hence relatively outdated.</p>
<p>Given the number of network elements and the relate complexity, I think we should consider doing a talk on each of them. The talk doesn't have to be of a particular length, so some network elements might have shorter or longer presentations.</p>
<p>Looking at the checklist below, we already have 14 items. Covering this in OsmoDevCall is not an option, it would take too long (14 months if no other topic would be covered in between). So it is going to be on a separate schedule.</p>
<p>I would consider each presentation should then be prominently linked from the redmine project page of each network element, next to the user manual.</p>
<p>We may of course still be publishing those via the OsmoDevCall "event" on media.ccc.de, so all videos are in one location.</p>
<p>I think every presentation should start with a quick picture at the overal diagram of netwokr elements, describe the surrounding elements and their interfaces to then look in detail at the specific element that ist he subject of the talk.</p>
It should cover
<ul>
<li>basic configuration to get it started / connected</li>
<li>VTY for state introspection ("ar alle connections up?", ...)</li>
<li>looking at logs / protocol traces</li>
<li>practical demo; looking at what happens in pcaps + logs for some basic transaction like LU, SMS, voice call.</li>
</ul> libosmo-sccp + libosmo-sigtran - Feature #5679 (In Progress): unsupported SCCP user primitive N-P...https://osmocom.org/issues/56792022-09-12T18:25:30Zpespin
<p>As seen in osmo-hnbgw when receiving an M3UA NTFY:<br /><pre>
20220912180716266 DLINP <0007> stream.c:445 [CONNECTED] osmo_stream_cli_fd_cb(): connected read
20220912180716266 DLINP <0007> stream.c:324 [CONNECTED] osmo_stream_cli_read(): message received
20220912180716267 DLSS7 <0011> osmo_ss7.c:1906 0: asp-asp-clnt-msc-0: xua_cli_read_cb(): sctp_recvmsg() returned 24 (flags=0x80)
20220912180716267 DLM3UA <0014> m3ua.c:714 0: asp-asp-clnt-msc-0: Received M3UA Message (SNM:DAVA)
20220912180716267 DLM3UA <0014> xua_snm.c:403 0: asp-asp-clnt-msc-0: Rx DAVA() for 0.23.4/0,
20220912180716267 DLSCCP <0012> sccp_user.c:175 Delivering N-PCSTATE.indication to SCCP User 'SCCP Management'
20220912180716267 DLSCCP <0012> sccp_scmg.c:298 unsupported SCCP user primitive N-PCSTATE.indication <======= libosmo-sccp.git scmg_prim_cb()
20220912180716267 DLSCCP <0012> sccp_user.c:175 Delivering N-PCSTATE.indication to SCCP User 'OsmoHNBGW' <===== IT IS FURTHER DELIVERED UPWARDS DESPITE NOT BEING SUPPORTED?
20220912180716267 DMAIN <0000> hnbgw_cn.c:473 sccp_sap_up(N-PCSTATE.indication)
20220912180716267 DMAIN <0000> hnbgw_cn.c:504 Received unknown prim 2562 from SCCP USER SAP <===== OSMO_HNBGW DOESN'T KNOW WHAT TO DO WITH IT
</pre></p>
<p><a class="user active" href="https://osmocom.org/users/7">laforge</a> would you mind providing feedback on what you think would need to be done here?</p> OsmoMSC - Bug #5197 (New): msc_i Unimplemented msg type: HANDOVER PERFORMEDhttps://osmocom.org/issues/51972021-07-12T14:18:36Zpespin
<p>As seen on a running osmo-msc:<br /><pre>
<0010> ran_msg_a.c:848 msc_i(IMSI-...:MSISDN-...:TMSI-0x...:GERAN-A-65:PAGING_RESP)[0x...]{READY}: RAN decode: BSSMAP: Unimplemented msg type: HANDOVER PERFORMED
</pre></p>
<p>Seems the message type is missing in ran_a_decode_bssmap. Is this expected? what's missing?</p> OsmoMSC - Bug #5196 (New): Verify several "event not permitted" log lines in unit testshttps://osmocom.org/issues/51962021-07-12T11:48:53Zpespin
<pre>
pespin ~/dev/sysmocom/git/osmo-msc $ ag "not permitted" tests/msc_vlr/ | grep Event
tests/msc_vlr/msc_vlr_test_gsm_authen.err:60:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:649:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:1480:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:1793:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:2058:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:2324:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:3242:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_ms_timeout.err:814:DMSC msc_a(IMSI-901700000004620:GERAN-A:LU){MSC_A_ST_WAIT_CLASSMARK_UPDATE}: Event MSC_A_EV_UNUSED not permitted
</pre>
<p>We should check whether those events are indeed not expected and only triggered by tests, or whether they can happen and hence we should allow them and handle them properly in the FSM.</p>
<p>Similar to:<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-msc/+/24916">https://gerrit.osmocom.org/c/osmo-msc/+/24916</a> msc_a.c: Allow MSC_A_EV_CN_CLOSE in state MSC_A_ST_RELEASING</p> Cellular Network Infrastructure - Bug #5188 (New): BSSMAP Cell Identifier IE vs. Cell Identifier ...https://osmocom.org/issues/51882021-06-23T00:43:19Zneelsnhofmeyr@sysmocom.de
<p>In libosmocore, we have enum CELL_IDENT, which gets used in both of<br /> Cell Identifier IE (3GPP TS 48.008 3.2.2.17)<br />and<br /> Cell Identifier List IE (3GPP TS 48.008 3.2.2.27)</p>
<p>The similar meaning and structuring of these two IEs suggests that the List IE<br />is simply a bunch of the plain Cell Identifier. However, if you read in 3GPP TS<br />48.008, comparing 3.2.2.17 and 3.2.2.27, there is this odd difference:</p>
<p>3.2.2.17, Cell Identifier IE:</p>
<pre><code>0000 CGI<br /> 0001 LAC+CI<br /> 0010 CI<br /> 0011 No cell</code></pre>
<pre><code>1000 PLMN+LAC+RNC (<del>> E-UTRAN)<br /> 1001 RNC (</del>> E-UTRAN)<br /> 1010 LAC+RNC (-> E-UTRAN)<br /> 1011 SAI<br /> 1100 LAC+RNC+CI</code></pre>
<p>3.2.2.27a, Cell Identifier List Segment:</p>
<pre><code>0000 CGI<br /> 0001 LAC+CI<br /> 0010 CI<br /> 0011 No cell</code></pre>
<pre><code>0100 LAI<br /> 0101 LAC<br /> 0110 entire BSS<br /> 0111 MCC+MNC</code></pre>
<p>I noticed this because I was trying to check for the correct target cell <br />identifier in the BSSMAP Handover Request message; we send a LAI cell <br />identification in the Cell Identifier IE. wireshark shows the LAI cell<br />identifer the same way that osmo-msc intends to encode it, but the TTCN3 <br />BSSAP_Templates fail to parse this LAI cell identifier.</p>
<p>So I added this cell id type to BSSMAP_IE_CellIdentifier in<br />./deps/titan.ProtocolModules.BSSMAP/src/BSSAP_Types.ttcn. and just to confirm<br />that I'm right i took a quick look in the spec, and then found that the ttcn <br />definition is in fact on par with the spec: the LAI cell id is not<br />present in 3.2.2.17 at all!</p>
<p>Now, our libosmocore gsm/protocol/gsm_08_08.h and gsm0808_utils.h are based on<br />the assumption that the same cell identifiers are used in both of these IEs.</p>
<p>The osmo-bsc and osmo-msc neighbor config for inter-BSC handover is built<br />assuming that we can send the 3.2.2.27a cell identifiers in the Handover<br />Request's 'Cell Identifier (Target)' IE.</p>
<p>Apparently the spec intends otherwise.</p>
<p>The effect of this goes across several osmo cn components:</p>
<ul>
<li>We define enum CELL_IDENT in libosmocore.</li>
<li>osmo-bsc sends the Handover Request using the 'Cell Identifier (Serving)' and 'Cell Identifier (Target)' IEs.</li>
<li>osmo-msc parses these, possibly forwards in inter-MSC handover procedure.</li>
</ul>
<p>I'm not sure how to resolve this.</p>
<ul>
<li>We could just accept that we're using the 3.2.2.27a identifiers also in 3.2.2.17. It makes an awful lot of sense in fact.<br /> The wireshark implementation seems to agree with this point, though of course that's not the benchmark.<br /> It might pose an incompatibility with strictly spec conforming cn implementations.<br /> And we would need to extend the TTCN BSSAP_Types.ttcn with values that aren't strictly present in 3.2.2.17,<br /> if we want to test these cell identifier types in our test suite.</li>
</ul>
<ul>
<li>or we could endeavour to fix the identifiers that we use in the BSSMAP protocol according to spec, in osmo-bsc and osmo-msc
<ul>
<li>either we introduce two distinct enums -- that could ripple through a lot of the cell identifier API, ugly.</li>
<li>or we still use the same enum for both, but making distinctions in the implementations which values are used for which.</li>
</ul></li>
</ul>
<p>To enforce that, we may have to adjust which cell identifier types can be used in the neighbor configuration of osmo-bsc and osmo-msc,<br />or we find ways to, for example, convert all cell identifier types to a supported one.<br />I guess easiest would be to enforce full CGI everywhere.</p>
<p>Yet easier would be to highlight in the documentation that osmocom is capable of nonstandard cell identifiers,<br />and to conform to specs users should simply use the full CGI everywhere in the neighbor config.</p>
<p>Any insights or opinions on this?</p> osmo-sip-connector - Bug #5177 (New): respect dynamic RTP payload types of external SIPhttps://osmocom.org/issues/51772021-06-12T07:24:17Zlaforge
<p>As <a class="user active" href="https://osmocom.org/users/4282">keith</a> reported in OsmoDevCall on June 11, when an external SIP entity sends a SIP INVITE with SDP for AMR using a dynamic PT, osmo-sip-connector still sends AMR audio using a different (actually unassigned for this call/session) PT.</p>
<p>I guess this relates to the fact that 3GPP uses "pseudo static" PTs for the different codecs, i.e. it has defined that certain PT numbers from the dynamic PT range actually statically represent 3GPP codec types. Within Osmocom, we are sticking to the latter and may not have considered "Real" SIP/SDP compatibilty on the external interface.</p> OsmoHNBGW - Feature #5153 (In Progress): support hnbgw co-located GTP-U proxy (UPF)https://osmocom.org/issues/51532021-05-13T12:13:07Zlaforge
<p>In the current osmo-hnbgw implementation, we simply configure the hNB GTP-U data to go directly to the GGSN. This requires IP-level routing between the RAN and the CN, which is possible in most lab situations, but not possible in real operator networks.</p>
<p>So we'd need to add support for a GTP-U proxy to control a co-located osmo-mgw. That proxy would translate GTP flows on the RAN side to GTP flows on the CN side (each with their own IPs/TEIDs).</p>
<p>The problem faced here is a 1:1 identical situation to what we're facing in OsmoSGSN in <a class="issue tracker-1 status-1 priority-2 priority-default" title="Bug: OsmoSGSN doesn't trigger 3G paging if downlink GTP traffic arrives after long break (New)" href="https://osmocom.org/issues/5154">#5154</a>. So both should then be able to use that same GTP-U proxy component.</p>
<p>Further brainstorming about this problem revealed that we're actualy talking about the same as the "SGW-U" network element described in 3GPP TS 23.214, which is what 3GPP invented when they introduced the control/user plane separation into the 4G EPC.</p>
<p>The SGW-U is exactly a GTP-U proxy between the RAN and the CN side, and it even includes functions for buffering GTP-U packets during mobility related GTP-U tunnel modification. It also includes functions for notifying the control plane entity of the first downlink packet received (so it can trigger paging). The SGW-U is controlled by the PFCP protocol. Only very few features of PFCP are required (PFCP is also used for he PGW-U which is much more complex).</p>
So in fact, what we'd have to implement is
<ul>
<li>a minimalistic SGW-U with PFCP suport</li>
<li>functionality in osmo-hnbgw to control that SGW-U via PFCP</li>
</ul> OsmoBSC - Feature #4940 (Stalled): VAMOS support in OsmoBSChttps://osmocom.org/issues/49402021-01-12T13:52:23Zlaforge
<p>This ticket should document what needs to be done in terms of supporting <a class="wiki-page" href="https://osmocom.org/projects/cellular-infrastructure/wiki/VAMOS">VAMOS</a> from <a class="wiki-page" href="https://osmocom.org/projects/osmobsc/wiki">OsmoBSC</a>, and to track its status via check-lists and possibly sub-issues.</p>
<p>3GPP unfortuantely doesn't provide any specifications for VAMOS beyond the radio interface. Neither A-bis OML nor RSL specs did receive any related updates.</p>
On an abstract level, we (IMHO) have the following problem domains:
<ol>
<li>how to represent the second user for each lchan</li>
<li>how to configure VAMOS via OML</li>
<li>how to represent the VAMOS channels on RSL</li>
<li>how to include VAMOS decisions in the channel allocator for assignment and hand-over</li>
</ol>
<p>as for the "representation" and "RSL" side, my idea would be to use the concept of "shadow TRX", i.e. introduce a second, logical TRX for each real TRX. Then one subscriber is on the "real" TRX and the other subscriber on the "shadow" TRX. Our data structures and RSL currently have at leaset uint8_t for the TRX number, and in reality no more than 12 TRX are ever expected in one BTS. This means we could e.g. use one of the higher-order bits to decide between real / shadow. So e.g.</p>
<ul>
<li>TRX number (and IPA stream ID) 0x00: TRX 0 (real)</li>
<li>TRX number (and IPA stream ID) 0x01: TRX 1 (real)</li>
<li>TRX number (and IPA stream ID) 0x80: TRX 0 (shadow)</li>
<li>TRX number (and IPA stream ID) 0x81: TRX 1 (shadow)</li>
<li>...</li>
</ul> libosmocore - Bug #4842 (In Progress): gsm0408 test fails on several architectureshttps://osmocom.org/issues/48422020-11-03T13:06:31Zbunkbunk@stusta.de
<p><a class="external" href="https://buildd.debian.org/status/logs.php?pkg=libosmocore&ver=1.4.0-1">https://buildd.debian.org/status/logs.php?pkg=libosmocore&ver=1.4.0-1</a><br /> 25: gsm0408 FAILED (testsuite.at:156)</p>
<p>The pattern of the failures is<br />-LU with truncated IMSI MI: rc = -74 ok<br />-LU with too short IMSI MI (12345): rc = -74 ok<br />+LU with truncated IMSI MI: rc = -77 ok<br />+LU with too short IMSI MI (12345): rc = -77 ok</p>
<p>The root cause is likely related to<br />/usr/include/asm-generic/errno.h:#define EBADMSG 74 /* Not a data message <strong>/<br />/usr/include/mips64el-linux-gnuabi64/asm/errno.h:#define EBADMSG 77 /</strong> Not a data message */</p> OsmoBSC - Bug #4832 (Stalled): osmo-bsc hard-releases lchan if no MSC is foundhttps://osmocom.org/issues/48322020-10-25T20:52:07Zlaforge
<p>As described in <a class="issue tracker-1 status-7 priority-3 priority-high3" title="Bug: OsmocomBB Rx bit errors in dedicated mode (Stalled)" href="https://osmocom.org/issues/4829">#4829</a>:</p>
<p>So.... the problem is something else altogether, or at least a large part of the problem.</p>
For some reason, osmo-bsc these days <strong>immediately hard-releases the lchan</strong> if there is no MSC. There is no signaling sent back to the MS about this:
<ul>
<li>no spoofing of MM/CM (LU REJECT, CM SERV REJECT, ...) which is still understandable, as it's a layering violation and those messages normally originat e at the MSC</li>
<li><strong>No RR CHANNEL RELEASE is sent to the MS</strong>. That is a big fat bug.</li>
</ul>
<p>Instead, we simply immedaitely close the lchan on the BTS side. This of course means that from that point onwards there re only bit-errors in downlink in the UE.</p>
<pre>
DRSL INFO <0003> ../../../git/src/osmo-bsc/abis_rsl.c:1453 (bts=0) CHAN RQD: reason: Location updating (ra=0x0f, neci=0x01, chreq_reason=0x03)
DCHAN INFO <000f> ../../../git/src/osmo-bsc/lchan_select.c:247 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{UNUSED}: (type=SDCCH) Selected
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/abis_rsl.c:1657 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{UNUSED}: (type=SDCCH) MS: Channel Request: reason=LOCATION_UPDATE ra=0x0f ta=0
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:329 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{UNUSED}: Received Event LCHAN_EV_ACTIVATE
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:548 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{UNUSED}: state_chg to WAIT_TS_READY
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/gsm_data.c:861 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_TS_READY}: (type=SDCCH) MS Power level update requested: 15 dBm
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/gsm_data.c:893 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_TS_READY}: (type=SDCCH) MS Power level update (power class 0): 0 -> 7
DCHAN INFO <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:626 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_TS_READY}: (type=SDCCH) Activation requested: FOR_MS_CHANNEL_REQUEST voice=no MGW-ci=none type=SDCCH tch-mode=SIGNALLING encr-alg=A5/0 ck=none
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/timeslot_fsm.c:106 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_TS_READY}: Received Event LCHAN_EV_TS_READY
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:644 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_TS_READY}: state_chg to WAIT_ACTIV_ACK
DRSL DEBUG <0003> ../../../git/src/osmo-bsc/abis_rsl.c:476 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4,state=IN_USE) Tx RSL Channel Activate with act_type=INITIAL
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/abis_rsl.c:1152 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_ACTIV_ACK}: (type=SDCCH) Rx CHAN_ACTIV_ACK
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/abis_rsl.c:1164 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_ACTIV_ACK}: Received Event LCHAN_EV_RSL_CHAN_ACTIV_ACK
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:772 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_ACTIV_ACK}: (type=SDCCH) Tx RR Immediate Assignment
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:822 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_ACTIV_ACK}: state_chg to WAIT_RLL_RTP_ESTABLISH
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/abis_rsl.c:1899 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RLL_RTP_ESTABLISH}: (type=SDCCH) SAPI=0 ESTABLISH INDICATION
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/abis_rsl.c:1932 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RLL_RTP_ESTABLISH}: Received Event LCHAN_EV_RLL_ESTABLISH_IND
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:850 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RLL_RTP_ESTABLISH}: state_chg to ESTABLISHED
DRSL ERROR <0003> ../../../git/src/osmo-bsc/gsm_08_08.c:483 MM GSM48_MT_MM_LOC_UPD_REQUEST: IMSI-001010000000001: No suitable MSC for this Complete Layer 3 request found
DRSL DEBUG <0003> ../../../git/src/osmo-bsc/abis_rsl.c:644 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:1595 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{ESTABLISHED}: state_chg to WAIT_RF_RELEASE_ACK
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/bsc_subscr_conn_fsm.c:778 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RF_RELEASE_ACK}: conn SUBSCR_CONN(msc4294967295-conn4294967295_subscr-IMSI-001010000000001)[0x28adc0] detaches lchan (primary lchan)
DMSC ERROR <0007> ../../../git/src/osmo-bsc/bsc_subscr_conn_fsm.c:153 SUBSCR_CONN(msc4294967295-conn4294967295_subscr-IMSI-001010000000001)[0x28adc0]{INIT}: Unable to deliver BSSMAP Clear Request message, no MSC for this conn
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:1644 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RF_RELEASE_ACK}: lchan detaches from conn SUBSCR_CONN(msc4294967295-conn4294967295_subscr-IMSI-001010000000001)[0x28adc0]
DLINP ERROR <0017> ../../git/src/input/ipaccess.c:412 Bad signalling message, sign_link returned error: No such file or directory.
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/abis_rsl.c:1152 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RF_RELEASE_ACK}: (type=SDCCH) Rx RF_CHAN_REL_ACK
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/abis_rsl.c:1184 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RF_RELEASE_ACK}: Received Event LCHAN_EV_RSL_RF_CHAN_REL_ACK
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:1206 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RF_RELEASE_ACK}: state_chg to WAIT_AFTER_ERROR
DLSS7 ERROR <0021> ../../git/src/m3ua.c:507 XUA_AS(as-clnt-A-0-m3ua)[0x253d70]{AS_DOWN}: Event AS-TRANSFER.req not permitted
DCHAN DEBUG <000f> ../../git/src/fsm.c:322 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_AFTER_ERROR}: Timeout of X3111
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:1550 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_AFTER_ERROR}: state_chg to UNUSED
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:382 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{UNUSED}: (type=SDCCH) Clearing lchan state
</pre>
<p>We should at the very minimum send a proper RR CHANNEL RELEASE to the MS, so it knows the channel is closed. That's the least we can do. However, it also means that the MS will likely start re-trying again and again. After all, it did not receive any reject with a cause value that would tell it to back off.</p>
<p>So I think we actually should either simply not hard-fast-close but let things run into some timeout (send SCCP connect request but then no response received?), or do the effort of spoofing a LU REJECT / CM SERVICE REJECt with a suitable Reject Cause IE ("Network Failure" or "Service option temporarily out of order" look good to me).</p>
<p>Another oddity about this problem is that it only shows if the MSC is absent when the BSC starts up. If the BSC has once seen the MSC, then it considers it 'eligible'. Even if the MSC then is gone at a later point, it will not go back to this hard-fast-clear behavior (at least not quickly?).</p> OsmoMSC - Bug #4830 (In Progress): LU reject when no authentication data in HLR but "authenticati...https://osmocom.org/issues/48302020-10-25T18:39:40ZlaforgeOsmoMSC - Bug #4721 (In Progress): osmo-msc creates evil-twin entries in the VLR when an already ...https://osmocom.org/issues/47212020-08-19T06:24:05Zlaforge
<p>When running this test locally against a (sanitize-enabled) osmo-msc, I get sporadic failures.</p>
<p>The differnence in the log files seems to start:</p>
<p>successful case:<br /><pre>
Wed Aug 19 08:10:24 2020 DVLR <000e> gsm_04_08.c:1394 SUBSCR(IMSI-262420000000013:MSISDN-491230000013:TMSI-0x01020304) VLR: update for IMSI=262420000000013 (MSISDN=491230000013)
</pre></p>
<p>failing case:<br /><pre>
Wed Aug 19 08:10:29 2020 DVLR <000e> gsm_04_08.c:1394 SUBSCR(IMSI-262420000000013:MSISDN-491230000013:TMSI-0x3BEDCD7C) VLR: update for IMSI=262420000000013 (MSISDN=491230000013) (NO CONN!)
</pre></p>
<p>The pcap file containing both cases is attached. They seem exactly identical, it's just that in the first (successful) case, there is a LU ACCEPT immediately, while in the second (failing) case, there is a LU REJECT after timeout of 5s.</p>
<p>I've seen the failure both when running a single test case, as well as when running the entire MSC_Tests.control in one batch.</p> libosmocore - Bug #4700 (Feedback): 'socket' C test fails when there is no IPv6https://osmocom.org/issues/47002020-08-09T18:06:40Zneelsnhofmeyr@sysmocom.de
<p>When building libosmocore (I did inside the ttcn3-tests docker container 'nonjenkins-bsc'), make check may fail the socket.c test;<br />when I revert this patch, the error no longer happens:</p>
<pre>
osmo_sock_init2: improve support for AF_UNSPEC
2c962f5de1eeea119cfac7d9d92db31c570353b9
I397c633931fd00d4f083955a3c49a40fb002d766
</pre>
<p>This is the test failure output:</p>
<pre><code>49: socket FAILED (testsuite.at:313)</code></pre>
<pre>
# -*- compilation -*-
49. testsuite.at:308: testing socket ...
../../../src/libosmocore/tests/testsuite.at:313: $abs_top_builddir/tests/socket/socket_test
--- experr 2020-08-09 17:51:39.081588010 +0000
+++ /src/make/libosmocore/tests/testsuite.dir/at-groups/49/stderr 2020-08-09 17:51:39.093588179 +0000
@@ -2,3 +2,7 @@
invalid: you have to specify either BIND or CONNECT flags
Unable to find a common protocol (IPv4 or IPv6) for local host: 127.0.0.1 and remote host: ::1.
Unable to find a common protocol (IPv4 or IPv6) for local host: ::1 and remote host: 127.0.0.1.
+unable to bind socket: ::1:0: Cannot assign requested address
+no suitable local addr found for: ::1:0
+Assert failed fd >= 0 ../../../src/libosmocore/tests/socket/socket_test.c:142
+/src/make/libosmocore/tests/testsuite.dir/at-groups/49/test-source: line 27: 20251 Aborted $abs_top_builddir/tests/socket/socket_test
--- expout 2020-08-09 17:51:39.081588010 +0000
+++ /src/make/libosmocore/tests/testsuite.dir/at-groups/49/stdout 2020-08-09 17:51:39.089588123 +0000
@@ -9,3 +9,9 @@
Checking osmo_sock_init2(AF_UNSPEC) must fail on mixed IPv6 & IPv4
Checking osmo_sock_init2(AF_UNSPEC) BIND + CONNECT on IPv4
Checking osmo_sock_init2(AF_UNSPEC) BIND + CONNECT on IPv6
+backtrace() returned 6 addresses
+/src/make/libosmocore/src/.libs/libosmocore.so.12(+0xdda0b) [0x7f89ded74a0b]
+/src/make/libosmocore/src/.libs/libosmocore.so.12(osmo_panic+0x14b) [0x7f89ded7491b]
+/src/make/libosmocore/tests/socket/socket_test(+0x1cc8) [0x558ed77eccc8]
+/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f89dd7d02e1]
+/src/make/libosmocore/tests/socket/socket_test(+0x1eda) [0x558ed77eceda]
../../../src/libosmocore/tests/testsuite.at:313: exit code was 134, expected 0
49. testsuite.at:308: 49. socket (testsuite.at:308): FAILED (testsuite.at:313)
</pre> OsmoMSC - Bug #4004 (New): lu_fsm_priv.rej_cause is never usedhttps://osmocom.org/issues/40042019-05-16T08:33:06Zlaforge
<p>In <code>vlr_lu_fsm.c</code>, <code>lu_fsm_priv.rej_cause</code> is set as a result to calls to <code>vlr_loc_update_cancel()</code>, but it doesn't appear to be used anywhere ?!?</p>
<p>This was introduced in<br /><pre>
commit 158095960b7f036480b50a9e0508d63579322db7
Author: Neels Hofmeyr <neels@hofmeyr.de>
Date: Fri Apr 6 02:57:51 2018 +0200
</pre></p> OsmoBSC - Feature #2781 (Feedback): Extend OsmBSC TTCN-3 test coverage regarding resource leakshttps://osmocom.org/issues/27812017-12-22T21:19:21Zlaforge
<p>let's collect ideas about what we need to test here</p> OsmoMSC - Feature #1974 (New): VLR: high water mark on subscriber storagehttps://osmocom.org/issues/19742017-03-08T14:54:50Zneelsnhofmeyr@sysmocom.de
<p>In libvlr, we (will) keep every subscriber in RAM as long as it still has valid auth tuples (3GPP TS 33.102 Annex C.2.3).<br />Most subscribers will still have auth tuples left upon detaching, so we would store <strong>all</strong> subscribers.</p>
<p>Implement a configurable way of limiting the number of subscribers kept in RAM, e.g. a fixed max size.<br />If this is reached, discard those subscribers that have been inactive for the longest time first.</p>