Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-02-28T00:28:49ZOpen Source Mobile Communications
Redmine OsmoBSC - Bug #6378 (New): Ericsson DUG 20 rejects SI2quaterhttps://projects.osmocom.org/issues/63782024-02-28T00:28:49Zkeith
<p>Sending SI2quater to the DUG20 results in</p>
<pre>
ERROR REPORT (cause=Radio Resource not available [ 21 01 80 ])
</pre>
<p>For what it may be worth, the SI and the error are in the attached pcap.</p>
<p>Maybe the BTS software version I have simply does not support it?</p> OsmoMSC - Bug #6358 (Closed): SMS from 4G fails - RP-DATA (MO) without DST or TPDU ?!?https://projects.osmocom.org/issues/63582024-02-13T00:34:55Zkeith
<p>WE currently cannot send SMS from a UE on 4G RAN</p>
<p>RP-DATA (MO) without DST or TPDU ?!?</p>
<pre>
20240213001943906 DLSMS DEBUG trans(SMS IMSI-334070000000968:MSISDN-68070122968:TMSI-0x1DCB852B:EUTRAN-SGs:CM_SERVICE_REQ callref-0x4000000c tid-8) RX_RP-DATA: src_len=0, dst_len=0 ud_len=15 (gsm_04_11.c:768)
20240213001943906 DLSMS ERROR trans(SMS IMSI-334070000000968:MSISDN-68070122968:TMSI-0x1DCB852B:EUTRAN-SGs:CM_SERVICE_REQ callref-0x4000000c tid-8) RP-DATA (MO) without DST or TPDU ?!? (gsm_04_11.c:775)
20240213001943906 DLSMS NOTICE trans(SMS IMSI-334070000000968:MSISDN-68070122968:TMSI-0x1DCB852B:EUTRAN-SGs:CM_SERVICE_REQ callref-0x4000000c tid-8) TX: SMS RP ERROR, cause 96 (Invalid Mandatory Information) (gsm_04_11.c:714)
</pre>
<p>Maybe this is due to a change in latest open5gs?</p> OsmoBSC - Bug #6324 (New): Making a data call results in B0RKEN lchanshttps://projects.osmocom.org/issues/63242024-01-05T20:31:49Zkeith
<p>I made a data call from a GSM modem and ended up with a CHAN NACK from osmo-bts (as is to be expected, I suppose)</p>
<p>Should we enhance osmo-bsc's NACK handling to do something a little more helpful than just B0RK the channel?</p> OsmoBTS - Bug #6180 (Resolved): ASSERT in l1sap_tch_indhttps://projects.osmocom.org/issues/61802023-09-14T21:35:48Zkeith
<p>On a sysmoBTS with the latest release, I observed regularly hitting this ASSERT at <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/33832/5/src/common/l1sap.c#1982">https://gerrit.osmocom.org/c/osmo-bts/+/33832/5/src/common/l1sap.c#1982</a></p>
<pre><code class="c syntaxhl"> <span class="k">case</span> <span class="n">RSL_CMOD_SPD_SIGN</span><span class="p">:</span>
<span class="k">default</span><span class="o">:</span> <span class="cm">/* shall not happen */</span>
<span class="n">OSMO_ASSERT</span><span class="p">(</span><span class="mi">0</span><span class="p">);</span>
<span class="err">}</span>
</code></pre>
<p>I've patched to avoid this ASSERT based on <a class="user active" href="https://projects.osmocom.org/users/67">fixeria</a> 's advice on IRC to get this BTS back up and running, so I can't reproduce right now. <br />(I've only installed the release on one system)</p>
<p>Here's a backtrace I did grab from the terminal scrollback, probably not very useful:</p>
<pre>
((*))
|
/ \ OsmoBTS
Assert failed 0 ../../../git/src/common/l1sap.c:1983
backtrace() returned 0 addresses
Program received signal SIGABRT, Aborted.
0x432dcf74 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x432dcf74 in raise () from /lib/libc.so.6
#1 0x432de358 in abort () from /lib/libc.so.6
#2 0xb6e778d4 in osmo_panic_default (args=..., fmt=0x0)
at /usr/src/debug/libosmocore/1.9.0+gitrAUTOINC+aca2c724ae-r2.18.0/git/src/core/panic.c:45
#3 osmo_panic (fmt=0x5f448 "Assert failed %s %s:%d\n")
at /usr/src/debug/libosmocore/1.9.0+gitrAUTOINC+aca2c724ae-r2.18.0/git/src/core/panic.c:80
#4 0x0005098c in l1sap_tch_ind (tch_ind=<optimized out>, l1sap=<optimized out>, trx=0xb6b5a038)
at /usr/src/debug/osmo-bts/1.7.0+gitAUTOINC+e97834f2db-r0.18/git/src/common/l1sap.c:1983
#5 l1sap_up (trx=trx@entry=0xb6b5a038, l1sap=<optimized out>)
at /usr/src/debug/osmo-bts/1.7.0+gitAUTOINC+e97834f2db-r0.18/git/src/common/l1sap.c:2184
#6 0x00051b34 in add_l1sap_header (trx=trx@entry=0xb6b5a038, rmsg=<optimized out>, lchan=<optimized out>,
chan_nr=<optimized out>, fn=5084, ber10k=1184, lqual_cb=102, rssi=-104 '\230', ta_offs=192, is_sub=0 '\000')
at /usr/src/debug/osmo-bts/1.7.0+gitAUTOINC+e97834f2db-r0.18/git/src/common/l1sap.c:179
#7 0x00020b8c in l1if_tch_rx (trx=trx@entry=0xb6b5a038, chan_nr=chan_nr@entry=26 '\032',
l1p_msg=l1p_msg@entry=0x187060)
at /usr/src/debug/osmo-bts/1.7.0+gitAUTOINC+e97834f2db-r0.18/git/src/osmo-bts-sysmo/tch.c:611
#8 0x000188e0 in handle_ph_data_ind (l1p_msg=0x187060, data_ind=0x187128, fl1=<optimized out>)
at /usr/src/debug/osmo-bts/1.7.0+gitAUTOINC+e97834f2db-r0.18/git/src/osmo-bts-sysmo/l1_if.c:976
#9 l1if_handle_ind (fl1=<optimized out>, msg=0x187060)
at /usr/src/debug/osmo-bts/1.7.0+gitAUTOINC+e97834f2db-r0.18/git/src/osmo-bts-sysmo/l1_if.c:1139
---Type <return> to continue, or q <return> to quit---q
</pre> OsmoPCU - Bug #6179 (Feedback): ASSERT in st_wait_releasehttps://projects.osmocom.org/issues/61792023-09-14T19:25:37Zkeith
<p>osmo-pcu from the recent release:</p>
<p>Here's a backtrace (from sysmobts with osmo-pcu-dbg and libosmocore-dbg symbols installed)<br /><pre>
Assert failed 0 ../../git/src/tbf_dl_fsm.c:309
backtrace() returned 0 addresses
Program received signal SIGABRT, Aborted.
0x432dcf74 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x432dcf74 in raise () from /lib/libc.so.6
#1 0x432de358 in abort () from /lib/libc.so.6
#2 0xb6eb38d4 in osmo_panic_default (args=..., fmt=0x0)
at /usr/src/debug/libosmocore/1.9.0+gitrAUTOINC+aca2c724ae-r2.18.0/git/src/core/panic.c:45
#3 osmo_panic (fmt=0x66fd4 "Assert failed %s %s:%d\n")
at /usr/src/debug/libosmocore/1.9.0+gitrAUTOINC+aca2c724ae-r2.18.0/git/src/core/panic.c:80
#4 0x00040f5c in st_wait_release (fi=<optimized out>, event=<optimized out>, data=<optimized out>)
at /usr/src/debug/osmo-pcu/1.3.0+gitAUTOINC+3ef173b980-r0.18/git/src/tbf_dl_fsm.c:309
#5 0xb6ea7824 in _osmo_fsm_inst_dispatch (fi=0x15e420, event=0, event@entry=3, data=data@entry=0x0, file=0x70098 "../../git/src/tbf.cpp",
line=line@entry=540) at /usr/src/debug/libosmocore/1.9.0+gitrAUTOINC+aca2c724ae-r2.18.0/git/src/core/fsm.c:875
#6 0x000356cc in gprs_rlcmac_tbf::poll_timeout (this=0x162920, pdch=0x154e64, poll_fn=223816, reason=<optimized out>)
at /usr/src/debug/osmo-pcu/1.3.0+gitAUTOINC+3ef173b980-r0.18/git/src/tbf.cpp:540
#7 0x0003585c in tbf_poll_timeout (tbf=<optimized out>, pdch=<optimized out>, poll_fn=<optimized out>, reason=<optimized out>)
at /usr/src/debug/osmo-pcu/1.3.0+gitAUTOINC+3ef173b980-r0.18/git/src/tbf.cpp:828
#8 0x0004cdf8 in pdch_ulc_expire_fn (ulc=0x1549d0, fn=223816, fn@entry=1395928)
at /usr/src/debug/osmo-pcu/1.3.0+gitAUTOINC+3ef173b980-r0.18/git/src/pdch_ul_controller.c:331
#9 0x00026a70 in pcu_rx_data_ind_pdtch (bts=bts@entry=0x154cd8, pdch=0x154e64, data=0x0, len=<optimized out>, fn=223816, meas=0xbefffb80,
meas@entry=0xbefffb78) at /usr/src/debug/osmo-pcu/1.3.0+gitAUTOINC+3ef173b980-r0.18/git/src/pcu_l1_if.cpp:396
#10 0x00015d70 in handle_ph_data_ind (fl1h=0x15de28, fl1h=0x15de28, l1p_msg=0x202ef8, data_ind=0x202fc0)
at /usr/src/debug/osmo-pcu/1.3.0+gitAUTOINC+3ef173b980-r0.18/git/src/osmo-bts-sysmo/sysmo_l1_if.c:220
</pre></p>
<p>It's always happening at line 540 in tbf.cpp:<br /><pre><code class="c syntaxhl"><span class="n">osmo_fsm_inst_dispatch</span><span class="p">(</span><span class="n">this</span><span class="o">-></span><span class="n">state_fi</span><span class="p">,</span> <span class="n">TBF_EV_MAX_N3105</span><span class="p">,</span> <span class="nb">NULL</span><span class="p">);</span>
</code></pre></p>
<p>Logs are messy, there's a lot going on.<br />Maybe attached log (at INFO) helps.</p> OsmoPCU - Bug #6002 (Resolved): retention or rapid re-creation of ms entries.https://projects.osmocom.org/issues/60022023-04-14T19:02:56Zkeith
<p>I mailed (privately) <a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> about this a couple of weeks ago.. because I saw a case where there were over 100,000 ms entries. It was in spanish so I won't repost here.</p>
<p><img src="https://projects.osmocom.org/attachments/download/6801/clipboard-202304142058-4itci.png" alt="" /></p>
<p>Can't really add more now anyway, other than just point that the issue exists. Those stats are not latest release, but the 100,000 was with latest.</p>
<p>This is just the latest to be added:</p>
<pre>
MS TLLI=92f209e0, IMSI=
Timing advance (TA): 7
Coding scheme uplink: MCS-1
Coding scheme downlink: MCS-7
Mode: EGPRS
MS class: 12
EGPRS MS class: 12
PACCH: 5
LLC queue length: 4
LLC queue octets: 36
RSSI: -110 dBm
Bit error rate: 0 %
Link quality: 7 dB
Burst timing offset: 3/4 bit
MS C value: 7 dB
Downlink TBF: TFI=1, state=ASSIGN
Current DL Throughput: 0 Kbps
MS Statistics:
Amount of DL CTRL messages scheduled: 113 (0/s 0/m 0/h 113/d)
</pre> OsmoBSC - Bug #5986 (New): PAGING impossible until CCCH LOAD IND is received from the BTShttps://projects.osmocom.org/issues/59862023-03-29T20:10:54Zkeith
<p>I noticed this with the RBS unit, that does not seem to be sending CCCH LOAD ind.</p>
<p>At <a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-bsc/src/branch/master/src/osmo-bsc/paging.c#L249">https://gitea.osmocom.org/cellular-infrastructure/osmo-bsc/src/branch/master/src/osmo-bsc/paging.c#L249</a> we fully delay all paging requests and log "Paging delayed: waiting for available slots at BTS" until such a LOAD ind has been received.</p>
<p>Maybe this check should be removed/relaxed if the vty param "paging load -1" is set?</p>
<p>Maybe the check for (bts_pag_st->free_chans_need != -1) and the above can be reordered?</p> OsmoBSC - Bug #5982 (Feedback): conn->fi is NULL in gscon_bssmap_clear()https://projects.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> OsmoBTS - Bug #5944 (In Progress): DTXu + AMR on TCH/H appears to be not usable on osmo-bts-sysmohttps://projects.osmocom.org/issues/59442023-03-11T05:12:25Zkeith
<p>The problem is that conversation is uncomfortable bordering on impossible due to random lost words and cut off of initial speech after silence periods.</p>
<p>I've been experimenting sending the AMR RTP stream into decoders or SIP endpoints, (all using libopencore-amr) and also, without using any external MNCC, thereby only having the the audio stream pass through osmo-mgw before going to a B-leg MS. I observe the problem in all cases.</p>
<p>I've put quite some hours into this so far, without being able to achieve any improvements. Rather than leave it all fade from memory, I'll just make a quick note of the main points of what was observed:</p>
<p>It all seems fine as long as you have sequences of speech followed by SID_FIRST_P1, SID_FIRST_P2, then eventually an ONSET, followed by speech frames... rinse and repeat. This is fine.</p>
<p>When it goes wrong is if you have a situation where (because of the timing of the VAD) you get either a SID_FIRST_INH or a SID_UPDATE_INH, in these cases, what I've observed is that after the SID_UPDATE_INH, the L1 does not seem to be sending us any Speech frames, (just TCH/H with no payload) even though I am speaking. Eventually, there will be an ONSET followed by speech frames.</p>
<p>I may be wrong, but I don't think there's anything that osmo-bts is doing or can do about this, so I'm pretty convinced at this point that is is an L1 problem, and therefore will not (cannot?) be fixed. I'm aware that there is code in libosmocore to deal with all this weird interleaving and such that goes on in AMR DTX, but we don't use any of it in osmo-bts-sysmo.</p>
<p>The pcap comes from an osmo-bts with some modifications to logging and RTP marking, (ignore the BAD AMR frames following ONSET - that's a hack but not relevant) the main point would be to observe what is happening around and after packet no 1482 - Note all that PH-DATA.ind TCH/H with no payload. I am speaking then.</p> OsmoBTS - Bug #5925 (Resolved): dtx downlink causing ABORT in osmo-bts-sysmohttps://projects.osmocom.org/issues/59252023-02-27T21:58:17Zkeith
<p>With param <strong>dtx downlink</strong> and making a call, causes</p>
<pre>
==24631== Process terminating with default action of signal 6 (SIGABRT)
==24631== at 0x6612E87: raise (raise.c:51)
==24631== by 0x66147F0: abort (abort.c:79)
==24631== by 0x5D648AF: osmo_panic (in /usr/lib/x86_64-linux-gnu/libosmocore.so.20.0.0)
==24631== by 0x114E8E: msgb_pull (msgb.h:407)
==24631== by 0x116751: ph_tch_req (l1_if.c:508)
==24631== by 0x116A08: ph_tch_req (l1_if.c:564)
==24631== by 0x116CE9: bts_model_l1sap_down (l1_if.c:632)
==24631== by 0x164A1F: l1sap_down (l1sap.c:1849)
==24631== by 0x16285D: l1sap_tch_rts_ind (l1sap.c:1324)
==24631== by 0x164821: l1sap_up (l1sap.c:1809)
==24631== by 0x117637: handle_ph_readytosend_ind (l1_if.c:886)
==24631== by 0x118438: l1if_handle_ind (l1_if.c:1119)
</pre>
<p>ph_tch_req() calls itself passing l1sap->oph.msg as msg<br />then<br />msgb_pull(msg, sizeof(*l1sap));<br />is called.</p> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://projects.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> Cellular Network Infrastructure - Bug #5856 (Resolved): Very annoying "this BTS model does not su...https://projects.osmocom.org/issues/58562023-01-14T23:27:07Zkeith
<p>Since some months ago, when connecting osmo-bts-sysmo to a remote osmo-bsc that is not directly on the LAN, (and very occasionally on the LAN), but rather on some higher latency link, I am often seeing</p>
<p><strong>common/oml.c:991 OC=<abbr title="03">CHANNEL</abbr> INST=(00,00,00): SET CHAN ATTR: this BTS model does not support TSC 7 != BSIC-BCC 0</strong></p>
<p>Seemingly because in the OML bringup we are sending <strong>Set CHAN attrs</strong> before we have sent <strong>Set BTS attrs</strong></p>
<p>I don't know what controls this sequence, but maybe it would be good if that were a little more robust.</p> OsmoHLR - Bug #5854 (Resolved): Memory leak: many 1000s of proxy_subscr_listentryhttps://projects.osmocom.org/issues/58542023-01-13T05:34:32Zkeith
<p>After running osmo-hlr with a dGSM setup for a few hours, memory consumption points to an obvious leak, and there are thousands of</p>
<pre>
struct proxy_subscr_listentry contains 944 bytes in 1 blocks (ref 0) 0x55f7cf8ba070
struct proxy_subscr_listentry contains 944 bytes in 1 blocks (ref 0) 0x55f7cf8e4960
struct proxy_subscr_listentry contains 944 bytes in 1 blocks (ref 0) 0x55f7cf8e5120
</pre>
<p>I <em>AM</em> running a few patches on master, but nothing that allocates a <strong>proxy_subscr_listentry</strong></p> OsmoSGSN - Bug #5725 (Resolved): Assert failed mm->gb.mm_state_fsm->state != ST_MM_IDLE sgsn_libg...https://projects.osmocom.org/issues/57252022-10-24T19:16:44Zkeith
<p>Just happened to notice a coredump due to hitting this in sgsn_libgtp.c:771</p>
<pre><code class="c syntaxhl"><span class="n">OSMO_ASSERT</span><span class="p">(</span><span class="n">mm</span><span class="o">-></span><span class="n">gb</span><span class="p">.</span><span class="n">mm_state_fsm</span><span class="o">-></span><span class="n">state</span> <span class="o">!=</span> <span class="n">ST_MM_IDLE</span><span class="p">);</span>
</code></pre> OsmoBSC - Bug #5717 (Resolved): ARFCN wrong in meas report system in multi-band BSShttps://projects.osmocom.org/issues/57172022-10-17T20:53:03Zkeith
<p>If you setup osmo-bsc with two BTS in one band and a third BTS in another band, then it seems that something is messed up with the index to arfcn translation. The meas report system reports the wrong ARFCN. AS much internally as in the meas feed.</p>
<p>It seems to affect Handover, as in HO then doesn't work.</p>
<p>I think it has something to do with this:<br /><pre><code class="c syntaxhl">
<span class="kt">int</span> <span class="nf">gsm48_parse_meas_rep</span><span class="p">(</span><span class="k">struct</span> <span class="n">gsm_meas_rep</span> <span class="o">*</span><span class="n">rep</span><span class="p">,</span> <span class="k">struct</span> <span class="n">msgb</span> <span class="o">*</span><span class="n">msg</span><span class="p">)</span>
<span class="p">{</span>
<span class="k">struct</span> <span class="n">gsm48_hdr</span> <span class="o">*</span><span class="n">gh</span> <span class="o">=</span> <span class="n">msgb_l3</span><span class="p">(</span><span class="n">msg</span><span class="p">);</span>
<span class="kt">uint8_t</span> <span class="o">*</span><span class="n">data</span> <span class="o">=</span> <span class="n">gh</span><span class="o">-></span><span class="n">data</span><span class="p">;</span>
<span class="k">struct</span> <span class="n">gsm_bts</span> <span class="o">*</span><span class="n">bts</span> <span class="o">=</span> <span class="n">msg</span><span class="o">-></span><span class="n">lchan</span><span class="o">-></span><span class="n">ts</span><span class="o">-></span><span class="n">trx</span><span class="o">-></span><span class="n">bts</span><span class="p">;</span>
<span class="k">struct</span> <span class="n">bitvec</span> <span class="o">*</span><span class="n">nbv</span> <span class="o">=</span> <span class="o">&</span><span class="n">bts</span><span class="o">-></span><span class="n">si_common</span><span class="p">.</span><span class="n">neigh_list</span><span class="p">;</span>
<span class="k">struct</span> <span class="n">gsm_meas_rep_cell</span> <span class="o">*</span><span class="n">mrc</span><span class="p">;</span>
<span class="cm">/* SNIP SNIP */</span>
<span class="n">mrc</span> <span class="o">=</span> <span class="o">&</span><span class="n">rep</span><span class="o">-></span><span class="n">cell</span><span class="p">[</span><span class="mi">0</span><span class="p">];</span>
<span class="n">mrc</span><span class="o">-></span><span class="n">rxlev</span> <span class="o">=</span> <span class="n">data</span><span class="p">[</span><span class="mi">3</span><span class="p">]</span> <span class="o">&</span> <span class="mh">0x3f</span><span class="p">;</span>
<span class="n">mrc</span><span class="o">-></span><span class="n">neigh_idx</span> <span class="o">=</span> <span class="n">data</span><span class="p">[</span><span class="mi">4</span><span class="p">]</span> <span class="o">>></span> <span class="mi">3</span><span class="p">;</span>
<span class="n">mrc</span><span class="o">-></span><span class="n">arfcn</span> <span class="o">=</span> <span class="n">bitvec_get_nth_set_bit</span><span class="p">(</span><span class="n">nbv</span><span class="p">,</span> <span class="n">mrc</span><span class="o">-></span><span class="n">neigh_idx</span> <span class="o">+</span> <span class="mi">1</span><span class="p">);</span>
<span class="cm">/*SNIP SNIP */</span>
<span class="p">}</span>
</code></pre></p>
<p>Is that neigh_list getting setup ordered by band or something? I don't really grok all that bitvec.</p> OsmoBSC - Bug #5712 (New): LCLS FSM; Not possible to get out from NO_LONGER_LShttps://projects.osmocom.org/issues/57122022-10-14T23:39:23Zkeith
<p>While working on implementing LCLS Control from a SIP PBX attached to osmo sipcon and osmo-msc, I stumbled here:</p>
<p>With an Active (mobile to mobile) Call, and after having sent SIP re-Invites to take the PBX out of the Loop, the resulting LCLS Connect Control Messages are sent from MSC to connect, osmo-bsc has both call legs in ST_LOCALLY_SWITCHED. All Good. :-)</p>
<p>Now we will issue SIP re-Invites to put the PBX back into the loop, osmo-bsc will get LCLS-CONN-CTRL with control set to GSM0808_LCLS_CSC_RELEASE_LCLS (for both legs), and here the FSM works fine, We get the RELEASE for LEG A and go to LOCALLY_SWITCHED_WAIT_OTHER_BREAK then osmo-msc sends the other release and then both legs are in ST_NO_LONGER_LS. Once again, All good.</p>
<p>Now, let's issue again a SIP re-Invite to take the PBX back out of the loop (we finished playback of "your credit is low" or whatever):</p>
<p>So just to recap:</p>
<p>bssmap_handle_lcls_connect_ctrl() is ALWAYS going to call:</p>
<p>lcls_update_config()</p>
<p>followed by</p>
<p>lcls_apply_config();</p>
<p>OK, so now Leg A gets a GSM0808_LCLS_CSC_CONNECT, we update the config and we get to lcls_no_longer_ls_fn() where:<br />We call lcls_enable_possible() which returns false, because:</p>
<pre><code class="c syntaxhl"> <span class="k">if</span> <span class="p">(</span><span class="n">other_conn</span><span class="o">-></span><span class="n">lcls</span><span class="p">.</span><span class="n">control</span> <span class="o">!=</span> <span class="n">GSM0808_LCLS_CSC_CONNECT</span><span class="p">)</span> <span class="p">{</span>
<span class="n">LOGPFSM</span><span class="p">(</span><span class="n">conn</span><span class="o">-></span><span class="n">lcls</span><span class="p">.</span><span class="n">fi</span><span class="p">,</span> <span class="s">"Not enabling LS due to insufficient other control</span><span class="se">\n</span><span class="s">"</span><span class="p">);</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="p">}</span>
</code></pre><br />we break out of the FSM function here without having done anything, no state change<br />Next we come to apply the config. <br />As we are still in ST_NO_LONGER_LS, we fall off the end of the switch and hit the ASSERT :-(
<p>Now, If I comment that ASSERT it actually works, because when the LCLS_CONN_CTRL for the B-leg comes in right afterwards, we have already changed the config in the A leg (which is now other) and so lcls_enable_possible() returns true, we change to ST_LOCALLY_SWITCHED and fire LCLS_EV_OTHER_ENABLED at the A leg, which, you remember is still in ST_NO_LONGER_LS and now once again we do lcls_enable_possible(), which passes and both legs are now ST_LOCALLY_SWITCHED<br />Yay!</p>
<p>I see various solutions? here:</p>
<ol>
<li>I'm doing something wrong on the MSC side and sending LCLS_CONN_CTRL that osmo-bsc does not and should not expect [1]</li>
<li>The FSM should handle LCLS_EV_APPLY_CFG_CSC in ST_NO_LONGER_LS [2]</li>
<li>We change the state of the A leg to ST_NO_LCLS when lcls_enable_possible() fails? [3]</li>
<li>something else?</li>
</ol>
<p>[1] so BTW, osmo_bsc_lcls.c is peppered with OSMO_ASSERT() - I found out while hacking on this that a misbehaving MSC can very easily crash it with the "wrong" LCLS CONNECT CONTROL messages. Should it not be a little more robust?</p>
<p>[2] Isn't this wrong, if there's no handler for LCLS_EV_APPLY_CFG_CSC in lcls_no_longer_ls_fn() ??<br /><pre><code class="c syntaxhl"> <span class="p">[</span><span class="n">ST_NO_LONGER_LS</span><span class="p">]</span> <span class="o">=</span> <span class="p">{</span>
<span class="p">.</span><span class="n">in_event_mask</span> <span class="o">=</span> <span class="n">S</span><span class="p">(</span><span class="n">LCLS_EV_UPDATE_CFG_CSC</span><span class="p">)</span> <span class="o">|</span>
<span class="n">S</span><span class="p">(</span><span class="n">LCLS_EV_APPLY_CFG_CSC</span><span class="p">)</span> <span class="o">|</span> <span class="cm">/* <- we don't handle this in the action function */</span>
<span class="n">S</span><span class="p">(</span><span class="n">LCLS_EV_CORRELATED</span><span class="p">)</span> <span class="o">|</span>
<span class="n">S</span><span class="p">(</span><span class="n">LCLS_EV_OTHER_ENABLED</span><span class="p">)</span> <span class="o">|</span>
<span class="n">S</span><span class="p">(</span><span class="n">LCLS_EV_OTHER_DEAD</span><span class="p">),</span>
<span class="p">.</span><span class="n">out_state_mask</span> <span class="o">=</span> <span class="n">S</span><span class="p">(</span><span class="n">ST_NO_LONGER_LS</span><span class="p">)</span> <span class="o">|</span>
<span class="n">S</span><span class="p">(</span><span class="n">ST_REQ_LCLS_NOT_SUPP</span><span class="p">)</span> <span class="o">|</span>
<span class="n">S</span><span class="p">(</span><span class="n">ST_LOCALLY_SWITCHED</span><span class="p">),</span>
<span class="p">.</span><span class="n">name</span> <span class="o">=</span> <span class="s">"NO_LONGER_LS"</span><span class="p">,</span>
<span class="p">.</span><span class="n">action</span> <span class="o">=</span> <span class="n">lcls_no_longer_ls_fn</span><span class="p">,</span>
</code></pre></p>
<p>[3] currently the FSM won't allow it.</p> libosmo-abis - Bug #5592 (Resolved): E1 pcap: Syscall param write(buf) points to uninitialised by...https://projects.osmocom.org/issues/55922022-06-26T03:27:47Zkeith
<p>I just happened to notice this running osmo-bsc under valgrind.</p>
<pre>
==20097== Syscall param write(buf) points to uninitialised byte(s)
==20097== at 0x4E48471: write (write.c:26)
==20097== by 0x4DA8DE9: osmo_pcap_lapd_write (lapd_pcap.c:168)
==20097== by 0x4DA8433: send_ph_data_req (lapd.c:628)
==20097== by 0x4C94F5C: lapd_send_rej (lapd_core.c:536)
==20097== by 0x4C9A08A: lapd_rx_i (lapd_core.c:1574)
==20097== by 0x4C9AA8F: lapd_ph_data_ind (lapd_core.c:1708)
==20097== by 0x4DA7C55: lapd_receive (lapd.c:496)
==20097== by 0x4D96B2C: e1inp_rx_ts_lapd (e1_input.c:778)
==20097== by 0x4D9C97C: handle_ts_sign_read (e1d.c:78)
==20097== by 0x4D9D908: e1d_fd_cb (e1d.c:281)
==20097== by 0x4D1281B: poll_disp_fds (select.c:361)
==20097== by 0x4D12928: _osmo_select_main (select.c:399)
==20097== Address 0x1ffefffed7 is on thread 1's stack
==20097== in frame #1, created by osmo_pcap_lapd_write (lapd_pcap.c:129)
==20097==
</pre> OsmoMGW - Bug #5577 (Rejected): Not able to find a free endpointhttps://projects.osmocom.org/issues/55772022-06-12T15:33:04Zkeith
<pre>
20220612103006461 DLMGCP ERROR (trunk:0) Not able to find a free endpoint (mgcp_endp.c:290)
20220612103006461 DLMGCP NOTICE CRCX: cannot find endpoint "rtpbridge/*@mgw", cause=403 -- trying to identify trunk... (mgcp_protocol.c:398)
20220612103006461 DLMGCP NOTICE endpoint:none CRCX: creating new connection ... (mgcp_protocol.c:855)
20220612103006461 DLMGCP ERROR endpoint:none CRCX: no free endpoints available! (mgcp_protocol.c:860)
</pre>
<p>Indeed, "show mgcp active" shows all EP in use, but there are zero active calls.</p> OsmoBSC - Bug #5572 (Resolved): segfault with osmo-BSC in osmo_mgcpc_ep_ci_request (rare)https://projects.osmocom.org/issues/55722022-05-26T02:43:08Zkeith
<p>The line that crashed was added in <a class="external" href="https://cgit.osmocom.org/osmo-mgw/commit/?id=3ff71284fa90e5c26963db860590054f41169970">https://cgit.osmocom.org/osmo-mgw/commit/?id=3ff71284fa90e5c26963db860590054f41169970</a></p>
<p>We can run for a few days before hitting this.</p>
<p>I don't have much relevant lead-up log captured at this time, only a backtrace.<br />Last Log line on the console is:<br /><pre>
DMSC ERROR osmo_bsc_bssap.c:1284 SUBSCR_CONN(msc0-conn43820_subscr-IMSI-334020218960160-TMSI-0x6919a240)[0x555555aded00]{WAIT_CLEAR_CMD}: Event MT_DTAP not permitted
</pre></p>
<pre>
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff79ebd6d in osmo_mgcpc_ep_ci_request (ci=0x555555b2d570, verb=MGCP_VERB_DLCX, verb_info=0x0, notify=0x0, event_success=0, event_failure=0, notify_data=0x0)
at mgcp_client_endpoint_fsm.c:665
665 LOG_CI_VERB(ci, LOGL_DEBUG, "notify=%s\n", osmo_fsm_inst_name(ci->notify.fi));
(gdb) bt
#0 0x00007ffff79ebd6d in osmo_mgcpc_ep_ci_request (ci=0x555555b2d570, verb=MGCP_VERB_DLCX, verb_info=0x0, notify=0x0, event_success=0, event_failure=0, notify_data=0x0)
at mgcp_client_endpoint_fsm.c:665
#1 0x000055555559d52d in osmo_mgcpc_ep_ci_dlcx (ci=0x555555b2d570) at /usr/local/include/osmocom/mgcp_client/mgcp_client_endpoint_fsm.h:42
#2 0x000055555559d802 in assignment_reset (conn=0x555555b367c0) at assignment_fsm.c:134
#3 0x00005555555c84ad in gscon_release_lchans (conn=0x555555b367c0, do_rr_release=true, cause_rr=GSM48_RR_CAUSE_NORMAL) at bsc_subscr_conn_fsm.c:260
#4 0x00005555555c824e in gscon_fsm_wait_sccp_rlsd_onenter (fi=0x555555aded00, prev_state=6) at bsc_subscr_conn_fsm.c:215
#5 0x00007ffff7ad09d4 in state_chg (fi=0x555555aded00, new_state=7, keep_timer=false, timeout_ms=60000, T=-4, file=0x5555556b8876 "bsc_subscr_conn_fsm.c", line=971)
at fsm.c:694
#6 0x00007ffff7ad0a37 in _osmo_fsm_inst_state_chg (fi=0x555555aded00, new_state=7, timeout_secs=60, T=-4, file=0x5555556b8876 "bsc_subscr_conn_fsm.c", line=971) at fsm.c:743
#7 0x00007ffff7aebe4b in _osmo_tdef_fsm_inst_state_chg (fi=0x555555aded00, state=7, timeouts_array=0x55555571d300 <conn_fsm_timeouts>,
tdefs=0x5555557281a0 <gsm_network_T_defs>, default_timeout=-1, file=0x5555556b8876 "bsc_subscr_conn_fsm.c", line=971) at tdef.c:357
#8 0x00005555555cc763 in gscon_fsm_allstate (fi=0x555555aded00, event=4, data=0x7fffffffcd1c) at bsc_subscr_conn_fsm.c:971
#9 0x00007ffff7ad133e in _osmo_fsm_inst_dispatch (fi=0x555555aded00, event=4, data=0x7fffffffcd1c, file=0x5555556e8c96 "osmo_bsc_bssap.c", line=438) at fsm.c:860
#10 0x000055555566f32b in bssmap_handle_clear_cmd (conn=0x555555b367c0, msg=0x555555b19d00, length=4) at osmo_bsc_bssap.c:438
#11 0x0000555555673a0e in bssmap_rcvmsg_dt1 (conn=0x555555b367c0, msg=0x555555b19d00, length=4) at osmo_bsc_bssap.c:1172
#12 0x0000555555674997 in bsc_handle_dt (conn=0x555555b367c0, msg=0x555555b19d00, len=6) at osmo_bsc_bssap.c:1360
#13 0x000055555567fb3a in handle_data_from_msc (conn=0x555555b367c0, msg=0x555555b19d00) at osmo_bsc_sigtran.c:141
#14 0x0000555555680598 in sccp_sap_up (oph=0x555555b19d88, _scu=0x555555a61ca0) at osmo_bsc_sigtran.c:256
#15 0x00007ffff7a1acd4 in sccp_user_prim_up (scu=0x555555a61ca0, prim=0x555555b19d88) at sccp_user.c:177
#16 0x00007ffff7a17da2 in scu_gen_encode_and_send (conn=0x555555b3e690, event=11, xua=0x555555b189f0, primitive=1, operation=PRIM_OP_INDICATION) at sccp_scoc.c:805
#17 0x00007ffff7a188ee in scoc_fsm_active (fi=0x555555aaf730, event=11, data=0x555555b189f0) at sccp_scoc.c:1124
#18 0x00007ffff7ad162d in _osmo_fsm_inst_dispatch (fi=0x555555aaf730, event=11, data=0x555555b189f0, file=0x7ffff7a3bc68 "sccp_scoc.c", line=1698) at fsm.c:872
#19 0x00007ffff7a19daa in sccp_scoc_rx_from_scrc (inst=0x555555a61b00, xua=0x555555b189f0) at sccp_scoc.c:1698
#20 0x00007ffff7a150fd in scrc_rx_mtp_xfer_ind_xua (inst=0x555555a61b00, xua=0x555555b189f0) at sccp_scrc.c:479
#21 0x00007ffff7a1ae48 in mtp_user_prim_cb (oph=0x555555af8cc8, ctx=0x555555a61b00) at sccp_user.c:202
#22 0x00007ffff7a294a6 in deliver_to_mtp_user (osu=0x555555a61b48, xua=0x555555ad1120) at osmo_ss7_hmrt.c:95
#23 0x00007ffff7a29673 in hmdt_message_for_distribution (inst=0x555555a2b3c0, xua=0x555555ad1120) at osmo_ss7_hmrt.c:134
#24 0x00007ffff7a2a0a7 in m3ua_hmdc_rx_from_l2 (inst=0x555555a2b3c0, xua=0x555555ad1120) at osmo_ss7_hmrt.c:278
#25 0x00007ffff7a0b37f in m3ua_rx_xfer (asp=0x555555a602d0, xua=0x555555ad1120) at m3ua.c:577
#26 0x00007ffff7a0bb9b in m3ua_rx_msg (asp=0x555555a602d0, msg=0x555555adb750) at m3ua.c:732
#27 0x00007ffff7a27668 in xua_cli_read_cb (conn=0x555555a60bd0) at osmo_ss7.c:1950
#28 0x00007ffff7a96a3d in osmo_stream_cli_read (cli=0x555555a60bd0) at stream.c:327
#29 0x00007ffff7a9717f in osmo_stream_cli_fd_cb (ofd=0x555555a60bd0, what=1) at stream.c:446
#30 0x00007ffff7ac881c in poll_disp_fds (n_fd=12) at select.c:361
#31 0x00007ffff7ac8929 in _osmo_select_main (polling=0) at select.c:399
#32 0x00007ffff7ac8997 in osmo_select_main_ctx (polling=0) at select.c:455
#33 0x00005555555797f9 in main (argc=3, argv=0x7fffffffe4b8) at osmo_bsc_main.c:1043
</pre>
<pre>
(gdb) info locals
ep = 0x555555b2d350
fi = 0x555555b18960
cleared_ci = {ep = 0x555555b2d350, occupied = true, label = '\000' <repeats 63 times>, mgcp_client_fi = 0x0, pending = false, sent = false, verb = MGCP_VERB_DLCX, verb_info = {
addr = '\000' <repeats 45 times>, port = 0, endpoint = '\000' <repeats 511 times>, call_id = 0, ptime = 0, codecs = {CODEC_PCMU_8000_1, CODEC_PCMU_8000_1,
CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1}, codecs_len = 0,
ptmap = {{codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {
codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {
codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}}, ptmap_len = 0, x_osmo_ign = 0, x_osmo_osmux_use = false, x_osmo_osmux_cid = 0,
conn_mode = MGCP_CONN_NONE, param_present = false, param = {amr_octet_aligned_present = false, amr_octet_aligned = false}}, notify = {entry = {next = 0x0, prev = 0x0},
fi = 0x0, success = 0, failure = 0, data = 0x0}, got_port_info = false, rtp_info = {addr = '\000' <repeats 45 times>, port = 0, endpoint = '\000' <repeats 511 times>,
call_id = 0, ptime = 0, codecs = {CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1,
CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1}, codecs_len = 0, ptmap = {{codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {
codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {
codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}}, ptmap_len = 0,
x_osmo_ign = 0, x_osmo_osmux_use = false, x_osmo_osmux_cid = 0, conn_mode = MGCP_CONN_NONE, param_present = false, param = {amr_octet_aligned_present = false,
amr_octet_aligned = false}}, mgcp_ci_str = '\000' <repeats 32 times>}
(gdb) p ci
$1 = (struct osmo_mgcpc_ep_ci *) 0x555555b2d570
(gdb) p *ci
$2 = {ep = 0x555555b2d350, occupied = true, label = '\000' <repeats 63 times>, mgcp_client_fi = 0x0, pending = false, sent = false, verb = MGCP_VERB_DLCX, verb_info = {
addr = '\000' <repeats 45 times>, port = 0, endpoint = '\000' <repeats 511 times>, call_id = 0, ptime = 0, codecs = {CODEC_PCMU_8000_1, CODEC_PCMU_8000_1,
CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1}, codecs_len = 0,
ptmap = {{codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {
codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {
codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}}, ptmap_len = 0, x_osmo_ign = 0, x_osmo_osmux_use = false, x_osmo_osmux_cid = 0,
conn_mode = MGCP_CONN_NONE, param_present = false, param = {amr_octet_aligned_present = false, amr_octet_aligned = false}}, notify = {entry = {next = 0x0, prev = 0x0},
fi = 0x0, success = 0, failure = 0, data = 0x0}, got_port_info = false, rtp_info = {addr = '\000' <repeats 45 times>, port = 0, endpoint = '\000' <repeats 511 times>,
call_id = 0, ptime = 0, codecs = {CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1,
CODEC_PCMU_8000_1, CODEC_PCMU_8000_1, CODEC_PCMU_8000_1}, codecs_len = 0, ptmap = {{codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {
codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {
codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}, {codec = CODEC_PCMU_8000_1, pt = 0}}, ptmap_len = 0,
x_osmo_ign = 0, x_osmo_osmux_use = false, x_osmo_osmux_cid = 0, conn_mode = MGCP_CONN_NONE, param_present = false, param = {amr_octet_aligned_present = false,
amr_octet_aligned = false}}, mgcp_ci_str = '\000' <repeats 32 times>}
(gdb) p ci->notify
$3 = {entry = {next = 0x0, prev = 0x0}, fi = 0x0, success = 0, failure = 0, data = 0x0}
</pre> Ericsson RBS 6xxx - Bug #5571 (New): DUG can come up, but with Avail: "Power Off"https://projects.osmocom.org/issues/55712022-05-24T01:48:54Zkeith
<p>Sometimes, after starting osmo-bsc, The BTS will transmit, we even start to get Channel requests, but this is the status: <br /><pre>
OsmoBSC# show trx
TRX 0 of BTS 0 is on ARFCN 251
RF Nominal Power: 37 dBm, reduced by 0 dB, resulting BS power: 37 dBm
Radio Carrier NM State: Oper 'NULL', Admin 'Unlocked', Avail 'Power off'
RSL State: connected
Baseband Transceiver NM State: Oper 'NULL', Admin 'Locked', Avail 'Power off'
E1 Signalling Link:
E1 Line 0, Type e1d: Timeslot 1, Mode RSL
E1 TEI 0, SAPI 0
</pre></p>
<p>and of course we get such as this:</p>
<pre>
DRSL NOTICE <0003> abis_rsl.c:2193 (bts=0) CHAN RQD[Location updating]: no resources for SDCCH 0x4, retrying with TCH_F
DRLL DEBUG <0000> lchan_select.c:299 (bts=0) lchan_select_by_type(TCH_F)
DRLL DEBUG <0000> lchan_select.c:233 (bts=0) lchan_avail_by_type(TCH_F)
DRLL DEBUG <0000> lchan_select.c:65 looking for lchan TCH/F: (bts=0,trx=0) trx not usable
DRLL DEBUG <0000> lchan_select.c:65 looking for lchan TCH/F_PDCH as TCH/F without pchan switch: (bts=0,trx=0) trx not usable
DRLL DEBUG <0000> lchan_select.c:65 looking for lchan TCH/F_PDCH as TCH/F: (bts=0,trx=0) trx not usable
DRLL DEBUG <0000> lchan_select.c:65 looking for lchan TCH/F_TCH/H_SDCCH8_PDCH as TCH/F without pchan switch: (bts=0,trx=0) trx not usable
DRLL DEBUG <0000> lchan_select.c:65 looking for lchan TCH/F_TCH/H_SDCCH8_PDCH as TCH/F: (bts=0,trx=0) trx not usable
DRLL NOTICE <0000> lchan_select.c:305 (bts=0) Failed to select TCH_F channel
</pre>
<p>Stopping and restarting osmo-bsc will sooner ( or later :-/ ) get the TRX up....</p>
<p>Attached is osmo-bsc.log of the bring-up and pcap of same.</p>
<p>I suspect there is something happening in a certain order sometimes that causes this?</p> OsmoMSC - Bug #5559 (Stalled): OsmoMSC at 100% CPU and unresponsive for up to several minutes!https://projects.osmocom.org/issues/55592022-05-12T23:22:09Zkeith
<p>Not much more to say than the title I'm afraid.</p>
<p>So far, I've actually only noticed it on a system using the RBS and osmo-e1d. But I do not have conclusive proof that it is exclusively happening here.</p>
<p>I'm assuming a culprit might be the sms queue, but I'm not convinced because I'm not seeing it on other systems with more messages in the queue in the sqlite db - and this can be upwards of 1,000 SMS queued.</p> OsmoMGW - Bug #5533 (Resolved): MGW memory leak?https://projects.osmocom.org/issues/55332022-04-17T22:59:29Zkeith
<p>Running for about 12 hours:</p>
<pre>
OsmoMGW# show talloc-context application brief
talloc report on 'mgcp-callagent' (total 2421492238 bytes in 8180552 blocks)
telnet_connection contains 265 bytes in 4 blocks (ref 0) 0x5618bbc01c50
/etc/osmocom/osmo-mgw.cfg contains 26 bytes in 1 blocks (ref 0) 0x5618bbbfe670
struct sched_vty_opts contains 72 bytes in 1 blocks (ref 0) 0x5618bbbf7720
abis contains 48772 bytes in 8 blocks (ref 0) 0x5618bbb093e0
logging contains 5246 bytes in 16 blocks (ref 0) 0x5618bbb08d60
msgb contains 2421437856 bytes in 8180521 blocks (ref 0) 0x5618bbb08cf0
</pre>
<pre>
OsmoMGW# show talloc-context application full
full talloc report on 'mgcp-callagent' (total 2431021650 bytes in 8212742 blocks)
telnet_connection contains 89 bytes in 2 blocks (ref 0) 0x5618bbc01c50
struct telnet_connection contains 88 bytes in 1 blocks (ref 0) 0x5618d7e71a50
/etc/osmocom/osmo-mgw.cfg contains 26 bytes in 1 blocks (ref 0) 0x5618bbbfe670
struct sched_vty_opts contains 72 bytes in 1 blocks (ref 0) 0x5618bbbf7720
abis contains 48772 bytes in 8 blocks (ref 0) 0x5618bbb093e0
unixsocket contains 1 bytes in 1 blocks (ref 0) 0x5618bbb09630
ipa contains 1 bytes in 1 blocks (ref 0) 0x5618bbb095c0
e1inp contains 48770 bytes in 5 blocks (ref 0) 0x5618bbb09450
struct e1inp_line contains 48768 bytes in 3 blocks (ref 0) 0x5618bbc02470
struct osmo_use_count_entry contains 40 bytes in 1 blocks (ref 0) 0x5618bbc02350
rate_ctr.c:230 contains 440 bytes in 1 blocks (ref 0) 0x5618bbb47160
e1inp_sign_link contains 1 bytes in 1 blocks (ref 0) 0x5618bbb094c0
logging contains 4818 bytes in 12 blocks (ref 0) 0x5618bbb08d60
vty_logp_doc_str contains 1095 bytes in 1 blocks (ref 0) 0x5618bbb62090
vty_logp_cmd_str contains 208 bytes in 1 blocks (ref 0) 0x5618bbb61f50
vty_log_level_doc_str contains 888 bytes in 1 blocks (ref 0) 0x5618bbb488f0
vty_log_level_cmd_str contains 184 bytes in 1 blocks (ref 0) 0x5618bbb487d0
vty_log_level_doc_str contains 1023 bytes in 1 blocks (ref 0) 0x5618bbb46500
vty_log_level_cmd_str contains 205 bytes in 1 blocks (ref 0) 0x5618bbb463c0
struct log_target contains 310 bytes in 3 blocks (ref 0) 0x5618bbb09230
struct osmo_wqueue contains 96 bytes in 1 blocks (ref 0) 0x7f40194b0090
struct log_category contains 54 bytes in 1 blocks (ref 0) 0x5618bbb09340
struct log_info contains 904 bytes in 2 blocks (ref 0) 0x5618bbb08dd0
struct log_info_cat contains 864 bytes in 1 blocks (ref 0) 0x5618bbb08e60
msgb contains 2430967872 bytes in 8212717 blocks (ref 0) 0x5618bbb08cf0
E1D Raw TS contains 296 bytes in 1 blocks (ref 0) 0x5619b39bab40
E1D Raw TS contains 296 bytes in 1 blocks (ref 0) 0x5619b39ba9b0
E1D Raw TS contains 296 bytes in 1 blocks (ref 0) 0x5619b39ba820
[!! SNIP... SNIP 8,212,740 lines similar to above 3 !!]
E1D Raw TS contains 296 bytes in 1 blocks (ref 0) 0x5618bbc57b20
E1D Raw TS contains 296 bytes in 1 blocks (ref 0) 0x5618bbb443a0
E1D Raw TS contains 296 bytes in 1 blocks (ref 0) 0x5618bbb46c80
mgcp-msg contains 4232 bytes in 1 blocks (ref 0) 0x5618bbc4f790
</pre> OsmoMSC - Bug #5532 (Resolved): Assert failed osmo_use_count_get_put()https://projects.osmocom.org/issues/55322022-04-17T07:10:44Zkeith
<pre>
Apr 16 20:41:30 huautla-bsc osmo-msc[17647]: DMSC ERROR msc_a.c:1685 (IMSI-334020349750006:MSISDN-69610126097:TMSI-0x30156FAD) Cannot tx event to MSC-I, no such role defined
Apr 16 20:41:30 huautla-bsc osmo-msc[17647]: DBSSAP ERROR msc_a.c:881 msc_a(IMSI-334020162777078:MSISDN-69610141108:TMSI-0x4ADE6C87:GERAN-A-112952:CM_SERVICE_REQ)[0x56363376a020]{MSC_A_ST_AUTHENTICATED}: Deallocating active transactions failed
Apr 16 20:41:30 huautla-bsc osmo-msc[17647]: DBSSAP ERROR msc_a.c:881 msc_a(IMSI-334020501994454:MSISDN-69610124271:TMSI-0xB068C7BB:GERAN-A-112949:CM_SERVICE_REQ)[0x5636358a43b0]{MSC_A_ST_AUTHENTICATED}: Deallocating active transactions failed
Apr 16 20:41:30 huautla-bsc osmo-msc[17647]: DBSSAP ERROR msc_a.c:881 msc_a(IMSI-334020547509057:MSISDN-69610143481:TMSI-0x3E52487F:GERAN-A-112942:CM_SERVICE_REQ)[0x563638968e20]{MSC_A_ST_AUTHENTICATED}: Deallocating active transactions failed
Apr 16 20:41:30 huautla-bsc osmo-msc[17647]: DVLR ERROR vlr.c:916 SUBSCR(IMSI-334030256923813:MSISDN-69610142437:TMSI-0x9189A257) Rx GSUP LU Result without LU in progress
Apr 16 20:41:35 huautla-bsc osmo-msc[17647]: DBSSAP ERROR msub.c:360 msc_a(TMSI-0xA8049D6D:GERAN-A-112959:CM_SERVICE_REQ)[0x563635db18d0]{MSC_A_ST_VALIDATE_L3}: Cannot associate with VLR subscr, another connection is already active at IMSI-334020544609239:MSISDN-69610133008:TMSI-0xA8049D6D:GERAN-A-112944:CM_SERVICE_REQ
Apr 16 20:41:35 huautla-bsc osmo-msc[17647]: DBSSAP ERROR msub.c:362 msc_a(IMSI-334020544609239:MSISDN-69610133008:TMSI-0xA8049D6D:GERAN-A-112944:CM_SERVICE_REQ)[0x56363471c6f0]{MSC_A_ST_AUTHENTICATED}: Attempt to associate a second subscriber connection at TMSI-0xA8049D6D:GERAN-A-112959:CM_SERVICE_REQ
Apr 16 20:41:35 huautla-bsc osmo-msc[17647]: DBSSAP ERROR gsm_04_08.c:817 msc_a(TMSI-0xA8049D6D:GERAN-A-112959:CM_SERVICE_REQ)[0x563635db18d0]{MSC_A_ST_RELEASING}: subscriber not allowed to do a CM Service Request
Apr 16 20:41:35 huautla-bsc osmo-msc[17647]: DBSSAP ERROR msc_a.c:1630 msc_a(TMSI-0xA8049D6D:GERAN-A-112959:CM_SERVICE_REQ)[0x563635db18d0]{MSC_A_ST_RELEASING}: RAN decode error (rc=-5) for COMPL_L3 from MSC-I
Apr 16 20:41:36 huautla-bsc osmo-msc[17647]: DMM ERROR gsm_04_08.c:696 msc_a(TMSI-0x3FD0B53C:GERAN-A-112960:CM_SERVICE_REQ)[0x56363689ab60]{MSC_A_ST_COMMUNICATING}: CM Service Request with mismatching mobile identity: TMSI-0x3FD0B53C
Apr 16 20:41:36 huautla-bsc osmo-msc[17647]: Assert failed osmo_use_count_get_put(&msc_a->use_count, msc_a_cm_service_type_to_use(cm_service_type), -1) == 0 gsm_04_08.c:1516
</pre>
<p>Possibly related to problems arising from #5530<br />Of course, It would be nice to recover from whatever this is without a restart of the MSC, as that is quite disruptive.</p> OsmoMSC - Bug #5529 (Resolved): Inter BSC HO fails due to lack of MSC Preferred Codecs IEhttps://projects.osmocom.org/issues/55292022-04-14T09:30:47Zkeith
<p>Since <a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/27405">https://gerrit.osmocom.org/c/osmo-bsc/+/27405</a> osmo-bsc requires the MSC Preferred Codec List IE in an incoming handover request as it should according to 3GPP TS 48.008 3.2.1.8</p>
<p>However, osmo-msc does not send it. TTCN3 tests are passing because the test suite generates the IE but does not require it.</p>
<p>It is suggested on the mailing list that the possible (probable?) easier? better? solution to generating this IE in osmo-msc is to work on the neels/codecs branch. <br />Unfortunately, further to neels' refactoring work on the commits, plus an osmodevcall, it is still maybe representing quite some work load to get that through code review.</p>
<p>A possible workaround (for a locally working system) would be to revert<br /> <a class="external" href="https://cgit.osmocom.org/osmo-bsc/commit/?id=826ec9ff758c8a40fca2eaf6cca7989ff6471c83">https://cgit.osmocom.org/osmo-bsc/commit/?id=826ec9ff758c8a40fca2eaf6cca7989ff6471c83</a></p> OsmoBSC - Bug #5525 (Resolved): Multi BSS Handover: gsm_bts_cell_id() passed NULL btshttps://projects.osmocom.org/issues/55252022-04-12T07:33:20Zkeith
<p>Program received signal SIGSEGV, Segmentation fault. <br />gsm_bts_cell_id (cell_id=cell_id@entry=0x7ffde7820830, bts=0x0) at bts.c:538</p>
<p>Happens every time.</p>
<pre>
(gdb) bt
#0 gsm_bts_cell_id (cell_id=cell_id@entry=0x7ffdebd006c0, bts=0x0) at bts.c:538
#1 0x000055e114b47c50 in find_alternative_lchan (lchan=lchan@entry=0x7fe512ad67d0, include_weaker_rxlev=include_weaker_rxlev@entry=true,
request_upgrade_to_tch_f=request_upgrade_to_tch_f@entry=true) at handover_decision_2.c:1453
#2 0x000055e114b49417 in on_measurement_report (mr=<optimized out>) at handover_decision_2.c:1573
#3 0x000055e114b59b2f in ho_meas_rep (mr=0x7fe512ad6d50) at handover_logic.c:95
#4 ho_logic_sig_cb (subsys=<optimized out>, signal=<optimized out>, handler_data=<optimized out>, signal_data=<optimized out>) at handover_logic.c:316
#5 0x00007fe513a3a45c in osmo_signal_dispatch () from /lib/x86_64-linux-gnu/libosmocore.so.18
#6 0x000055e114aeaf09 in send_lchan_signal (resp=0x7fe512ad6d50, lchan=<optimized out>, sig_no=8) at abis_rsl.c:67
#7 rsl_rx_meas_res (msg=0x55e116746cd0) at abis_rsl.c:1469
#8 0x000055e114aec566 in abis_rsl_rx_dchan (msg=<optimized out>) at abis_rsl.c:1565
#9 0x000055e114af0ac5 in abis_rsl_rcvmsg (msg=0x55e116746cd0) at abis_rsl.c:3119
#10 0x00007fe5139e2e1d in handle_ts1_read () from /usr/local/lib/libosmoabis.so.10
#11 0x00007fe5139e343c in ipaccess_fd_cb () from /usr/local/lib/libosmoabis.so.10
#12 0x00007fe513a39ef3 in ?? () from /lib/x86_64-linux-gnu/libosmocore.so.18
#13 0x00007fe513a3a016 in osmo_select_main_ctx () from /lib/x86_64-linux-gnu/libosmocore.so.18
#14 0x000055e114ad867f in main (argc=<optimized out>, argv=<optimized out>) at osmo_bsc_main.c:1043
</pre> OsmoMSC - Bug #5491 (New): MT CSFB calls fail (only) first time after Airplane mode toggle (proba...https://projects.osmocom.org/issues/54912022-03-19T02:49:20Zkeith
<p>To reproduce:</p>
<p>With working EUTRAN and GERAN networks, toggle airplane mode. Phone (re)-ATTACHes to LTE network.</p>
<p>Call the phone:</p>
<p>In osmo-msc: (i've attached the entire debug log)</p>
<pre>
20220319023547480 DMM DEBUG msc_a(TMSI-0x2F655780:GERAN-A-50:LU)[0x55b8e91359b0]{MSC_A_ST_VALIDATE_L3}: LOCATION UPDATING REQUEST: MI=TMSI-0x2F655780 LU-type=NORMAL (gsm_04_
20220319023547480 DMM DEBUG msc_a(TMSI-0x2F655780:GERAN-A-50:LU)[0x55b8e91359b0]{MSC_A_ST_VALIDATE_L3}: USIM: old LAI: 334-07-101 (gsm_04_08.c:407)
20220319023547480 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 for MNCC: establish call: Paging Response action (expired) (paging.c:154)
20220319023547480 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 for MNCC: establish call: Removing Paging Request (paging.c:127)
20220319023547480 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 callref-0x13ad tid-255) Paging expired (gsm_04_08_cc.c:339)
20220319023547480 DMNCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 callref-0x13ad tid-255) tx MNCC_REL_IND (gsm_04_08_cc.c:237)
20220319023547480 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 callref-0x0 tid-255) Freeing transaction (transaction.c:230)
</pre>
<p>After this 1st try, the subsequent try succeeds:</p>
<pre>
20220319024811027 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 callref-0x13af tid-255) New transaction (transaction.c:218)
20220319024811027 DMNCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 callref-0x13af tid-255) rx MNCC_SETUP_REQ (gsm_04_08_cc.c:1979)
20220319024811027 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 for MNCC: establish call: Starting paging (paging.c:101)
20220319024814102 DMM DEBUG Tx AUTH REQ (rand = 07e7f2e89f5782be2bac726d7d90914a) (gsm_04_08.c:642)
20220319024814102 DMM DEBUG AUTH REQ (autn = e6ab0ad9e6a7000050ffb868d2a25996) (gsm_04_08.c:644)
20220319024815042 DMM DEBUG msc_a(IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684:GERAN-A-52:PAGING_RESP)[0x55b8e913d250]{MSC_A_ST_AUTH_CIPH}: MM UMTS AUTHENTICATION RESPONSE (res = 6ce1b1df36c7c61f) (gsm_04_08.c:1119)
20220319024815749 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 for MNCC: establish call: Paging Response action (success) (paging.c:154)
20220319024815749 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 for MNCC: establish call: Removing Paging Request (paging.c:127)
20220319024815749 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 callref-0x13af tid-255) Paging succeeded (gsm_04_08_cc.c:316)
</pre>
<p>There's a difference in show subscriber cache after an ATTACH via SGS as opposed to a complete LUR on GERAN (we have auth data):</p>
<pre>
show subscriber cache
Subscriber #00:
MSISDN: 12345174747
LAC / cell ID: 101 / 100
RAN type: EUTRAN-SGs
IMSI: 334070000000968
TMSI: 1E460BB7
IMEI: 35729207588080
IMEISV: 3572920758808001
Flags:
IMSI detached: false
Conf. by radio contact: true
Subscr. data conf. by HLR: true
Location conf. in HLR: true
Subscriber dormant: false
Received cancel location: false
MS not reachable: false
LA allowed: true
A3A8 last tuple (used 1 times):
seq # : 4
RAND : 17 8a 18 c2 62 8e 85 a5 fe a1 1b 03 c2 51 37 9a
SRES : a0 10 84 9a
Kc : 01 1d 45 1b 6c 47 74 00
Expires: never
Paging: not paging for 0 requests
SGs-state: SGs-ASSOCIATED
SGs-MME: mmec01.mmegi0002.mme.epc.mnc007.mcc334.3gppnetwork.org
Use count total: 1
Use count: 1 (attached)
</pre>
<pre>
show subscriber cache
Subscriber #00:
MSISDN: 12345174747
LAC / cell ID: 101 / 0
RAN type: EUTRAN-SGs
IMSI: 334070000000968
TMSI: 2F655780
Flags:
IMSI detached: false
Conf. by radio contact: true
Subscr. data conf. by HLR: true
Location conf. in HLR: true
Subscriber dormant: false
Received cancel location: false
MS not reachable: false
LA allowed: true
Expires: never
Paging: not paging for 0 requests
SGs-state: SGs-ASSOCIATED
SGs-MME: mmec01.mmegi0002.mme.epc.mnc007.mcc334.3gppnetwork.org
Use count total: 1
Use count: 1 (attached)
</pre>
<p>Assigning to myself; I do intend to fix it.</p>
<p>Would appreciate confirmation all the same from anybody else who has a working setup, or even some static analysis by those more familiar with this code.</p> OsmoSGSN - Bug #5349 (In Progress): Message for non-existing SNDCP Entity https://projects.osmocom.org/issues/53492021-12-09T20:57:14Zkeith
<p>It seems pretty easy to get into a state where the TLLI in the MM context is not matching that in the SNDCP.</p>
<pre>
MM Context for IMSI 262423203000396, IMEI 013895003719350, P-TMSI ecc8a829
MSISDN: 57057157010, TLLI: ecc8a829 HLR:
GMM State: Registered.NORMAL, Routeing Area: 334-07-1101-21, Cell ID: 0
MM State: Standby, RAN Type: GPRS/EDGE via Gb
SGSN MM Context Statistics:
Signalling Messages ( In): 45 (0/s 0/m 45/h 0/d)
Signalling Messages (Out): 21 (0/s 0/m 21/h 0/d)
User Data Messages ( In): 369 (0/s 0/m 369/h 0/d)
User Data Messages (Out): 288 (0/s 0/m 288/h 0/d)
User Data Bytes ( In): 37388 (0/s 0/m 37388/h 0/d)
User Data Bytes (Out): 56465 (0/s 0/m 56465/h 0/d)
PDP Context Activations : 1 (0/s 0/m 1/h 0/d)
SUSPEND Count : 0 (0/s 0/m 0/h 0/d)
Paging Packet Switched : 2 (0/s 0/m 2/h 0/d)
Paging Circuit Switched : 0 (0/s 0/m 0/h 0/d)
Routing Area Update : 14 (0/s 0/m 14/h 0/d)
OsmoSGSN# show snd
OsmoSGSN# show sndcp
State of SNDCP Entities
TLLI c6ada2d6 SAPI=3 NSAPI=5:
Defrag: npdu=289 highest_seg=2 seg_have=0x00000007 tot_len=1233
TLLI e9d026da SAPI=3 NSAPI=5:
Defrag: npdu=339 highest_seg=1 seg_have=0x00000003 tot_len=793
</pre>
<p>resulting in:</p>
<pre>
20211209214900128 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900148 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900149 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900170 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900170 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900188 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900210 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900210 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900230 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900231 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900248 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900248 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900267 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900267 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
</pre>
<p>My apologies - Over the last year or so I've suffered a memory leak for all the GRPS workings, I'll need to read up again to further debug this myself, but in the meantime, it should be reproducible if anyone wishes to take a look.</p>
<p><del>One way to trigger it seems to be cause a GPRS suspend by making a call</del> . In fact I can't reproduce this so easily. Something else is in the mix.</p>
<p>See the notes I erroneously posted on related issue <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: vty comand "show sndcp" can cause SEGV in vty_dump_sne() (Resolved)" href="https://projects.osmocom.org/issues/4824">#4824</a> , especially <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: vty comand "show sndcp" can cause SEGV in vty_dump_sne() (Resolved)" href="https://projects.osmocom.org/issues/4824#note-13">#4824-13</a></p>
<p>Marking high priority as I am observing this as a show stopper in production. <br />Thanks.</p> OsmoBTS - Bug #5338 (New): LMSDevice.cpp:261 Power parameters requested before Tx Frequency was s...https://projects.osmocom.org/issues/53382021-12-05T20:51:54Zkeith
<p>Posting in osmo-bts as I assume it is an osmo-bts issue, although it is observed with osmo-trx-lms as I don't currently have any other TRX hardware.</p>
<p>How to reproduce:<br />Bring up a BTS with osmo-trx-lms</p>
<p>such as:<br /><pre>
while [ 0 ] ; do sleep 1; sudo osmo-trx-lms -C osmo-trx-lms.cfg; done
</pre></p>
<pre>
# osmo-bts doesn't exit anymore, put it it a loop anyway:
while [ 0 ] ; do sleep 1; osmo-bts-trx -c osmo-bts-trx.cfg ; done
</pre>
<p>Once the BTS is up, drop it from the BSC:<br /><pre>
drop bts connection X oml
</pre><br />The bts will ramp the power down, then finally issue RFMUTE then start to bring it up again:</p>
<p>A bunch of stuff will happen here, that may or may not depend on the config, but the point is that eventually we get to:</p>
<pre>
Sun Dec 5 14:42:06 2021 DTRXDUL FATAL <0004> Transceiver.cpp:1309 Something went wrong in thread RxLower, requesting stop
Sun Dec 5 14:42:06 2021 DTRXCTRL INFO <0002> Transceiver.cpp:1031 [chan=0] response is 'RSP POWERON 0'
Sun Dec 5 14:42:06 2021 DDEV INFO <0005> LMSDevice.cpp:159 Closing LMS device
</pre>
<p>osmo-trx-lms exits and the shell restarts it:</p>
<p>Then we will see:<br /><pre>
Sun Dec 5 14:42:09 2021 DTRXCTRL INFO <0002> Transceiver.cpp:877 [chan=0] command is 'POWERON'
Sun Dec 5 14:42:09 2021 DDEV INFO <0005> LMSDevice.cpp:390 starting LMS...
Sun Dec 5 14:42:09 2021 DDEV ERROR <0005> LMSDevice.cpp:261 Power parameters requested before Tx Frequency was set! Providing band 900 by default...
</pre></p>
<p>ad infinitum...</p>
<p>Also if the sleep in the TRX loop is increased to say 5 seconds, then when osmo-trx-lms starts again, the BTS<br />has logged <strong>Shutting down BTS, exit 1, reason: No clock since TRX was started.</strong> and now needs manual intervention.<br />In this state, dropping the BTS just results in:<br />BTS_SHUTDOWN(bts0)[0x5618af2268f0]{WAIT_RAMP_DOWN_COMPL}: BTS is already being shutdown.</p>
<p>I now have to CTRL-QUIT the osmo-bts-trx process or <strong>killall -[3|9] osmo-bts-trx</strong> or somesuch :(</p>
<p>I could attach entire logs/configs et al, but I'd be very surprised if this is not 100% reproducible.</p> OsmoBSC - Bug #5324 (Resolved): MULTI BSS Handover: Target BTS is NULL, sigsegv in chan_counts_fo...https://projects.osmocom.org/issues/53242021-11-23T22:03:21Zkeith
<p>It looks like something with Multi BSS handover is broken:</p>
<pre>
DHODEC handover_decision_2.c:1470 (lchan 0.020 TCH_F SPEECH_AMR) (subscr subscr-IMSI-262423203000396-TMSI-0x7a3e1e7f) MEASUREMENT REPORT (1 neighbors)
DHODEC handover_decision_2.c:1475 (lchan 0.020 TCH_F SPEECH_AMR) (subscr subscr-IMSI-262423203000396-TMSI-0x7a3e1e7f) 0: arfcn=247 bsic=63 neigh_idx=0 rxlev=63 flags=0
DHODEC handover_decision_2.c:1522 (lchan 0.020 TCH_F SPEECH_AMR) (subscr subscr-IMSI-262423203000396-TMSI-0x7a3e1e7f) Avg RX level = -47 dBm, +0 dBm AFS bias = -47 dBm; Avg RX quality = 0, +0 AFS bias = 0
DHODEC handover_logic.c:241 (subscr subscr-IMSI-262423203000396-TMSI-0x7a3e1e7f) HO-none: There are explicit neighbors configured for this cell
DHODEC handover_logic.c:254 (subscr subscr-IMSI-262423203000396-TMSI-0x7a3e1e7f) HO-none: Found remote target cell(s) CGI[1]:{334-07-274-101}
Program received signal SIGSEGV, Segmentation fault.
0x00005555555b98de in chan_counts_for_bts (bts_counts=bts_counts@entry=0x7fffffff7a70, bts=0x0) at chan_counts.c:133
</pre>
<p>From a previous run:</p>
<pre>
#0 chan_counts_for_bts (bts_counts=bts_counts@entry=0x7fffffff7a10, bts=0x0) at chan_counts.c:137
#1 0x00005555555c0cad in candidate_set_free_tch (c=c@entry=0x7fffffff8240) at handover_decision_2.c:1030
#2 0x00005555555c2bd7 in collect_handover_candidate (lchan=lchan@entry=0x7ffff7e9f1f0, nmp=nmp@entry=0x7ffff7e9f36c, clist=clist@entry=0x7fffffff89b0,
candidates=candidates@entry=0x7fffffff899c, include_weaker_rxlev=include_weaker_rxlev@entry=false, rxlev_current=rxlev_current@entry=63, neighbors_count=0x7fffffff8914)
at handover_decision_2.c:1146
#3 0x00005555555c5813 in collect_candidates_for_lchan (lchan=lchan@entry=0x7ffff7e9f1f0, clist=clist@entry=0x7fffffff89b0, candidates=candidates@entry=0x7fffffff899c,
_rxlev_current=_rxlev_current@entry=0x7fffffff8998, include_weaker_rxlev=include_weaker_rxlev@entry=false) at handover_decision_2.c:1224
#4 0x00005555555c6af4 in find_alternative_lchan (lchan=lchan@entry=0x7ffff7e9f1f0, include_weaker_rxlev=include_weaker_rxlev@entry=false, request_upgrade_to_tch_f=false)
at handover_decision_2.c:1303
#5 0x00005555555c7f8f in on_measurement_report (mr=0x7ffff7e9f540) at handover_decision_2.c:1577
#6 0x00005555555d2647 in ho_meas_rep (mr=0x7ffff7e9f540) at handover_logic.c:95
#7 ho_logic_sig_cb (subsys=<optimized out>, signal=<optimized out>, handler_data=<optimized out>, signal_data=<optimized out>) at handover_logic.c:316
#8 0x00007ffff72e3ca4 in osmo_signal_dispatch (subsys=subsys@entry=3, signal=signal@entry=8, signal_data=signal_data@entry=0x7fffffffd170) at signal.c:118
#9 0x0000555555582a72 in send_lchan_signal (resp=0x7ffff7e9f540, lchan=<optimized out>, sig_no=8) at abis_rsl.c:67
#10 rsl_rx_meas_res (msg=msg@entry=0x555555bc0350) at abis_rsl.c:1455
#11 0x00005555555879e5 in abis_rsl_rx_dchan (msg=0x555555bc0350) at abis_rsl.c:1544
#12 abis_rsl_rcvmsg (msg=0x555555bc0350) at abis_rsl.c:3056
#13 0x00007ffff6eac542 in handle_ts1_read () from /usr/local/lib/libosmoabis.so.10
#14 0x00007ffff6eaca2b in ipaccess_fd_cb () from /usr/local/lib/libosmoabis.so.10
#15 0x00007ffff72e36fc in poll_disp_fds (n_fd=<optimized out>) at select.c:361
#16 _osmo_select_main (polling=<optimized out>) at select.c:393
#17 0x00007ffff72e37e6 in osmo_select_main_ctx (polling=<optimized out>) at select.c:449
#18 0x0000555555575909 in main (argc=<optimized out>, argv=<optimized out>) at osmo_bsc_main.c:1087
</pre>
<p>In candidate_set_free_tch ():</p>
<pre>
(gdb) p c->target
$13 = {ab = {arfcn = 249, bsic = 63 '?'}, cell_ids = {id_discr = CELL_IDENT_WHOLE_GLOBAL, id_list = {{global = {lai = {plmn = {mcc = 334, mnc = 7, mnc_3_digits = false},
lac = 274}, cell_identity = 102}, lac_and_ci = {lac = 334, ci = 7}, ci = 334, lai_and_lac = {plmn = {mcc = 334, mnc = 7, mnc_3_digits = false}, lac = 274}, lac = 334,
global_ps = {rai = {lac = {plmn = {mcc = 334, mnc = 7, mnc_3_digits = false}, lac = 274}, rac = 102 'f'}, cell_identity = 0}}, {global = {lai = {plmn = {mcc = 0, mnc = 0,
mnc_3_digits = false}, lac = 0}, cell_identity = 0}, lac_and_ci = {lac = 0, ci = 0}, ci = 0, lai_and_lac = {plmn = {mcc = 0, mnc = 0, mnc_3_digits = false}, lac = 0},
lac = 0, global_ps = {rai = {lac = {plmn = {mcc = 0, mnc = 0, mnc_3_digits = false}, lac = 0}, rac = 0 '\000'}, cell_identity = 0}} <repeats 126 times>}, id_list_len = 1},
bts = 0x0, rxlev = 63, rxlev_afs_bias = 0, free_tchf = 0, min_free_tchf = 0, free_tchh = 0, min_free_tchh = 0, next_tchf_reduces_tchh = 0, next_tchh_reduces_tchf = 0}
</pre> Cellular Network Infrastructure - Bug #5318 (Resolved): Depends: in osmocom packageshttps://projects.osmocom.org/issues/53182021-11-20T00:29:17Zkeith
<p>After the recent release, doing something like</p>
<pre>
apt install osmo-sgsn
</pre>
<p>on a Debian system (with opensuse repos) will leave osmo-sgsn unexpectedly broken as libgtp6 will not be updated, leaving osmo-sgsn without required symbols.</p>
<p>pabs3 on IRC says:</p>
<pre>
see the dh_makeshlibs and deb-shlibs manual pages,
basically put "libgtp 6 libgtp6 (>= 1.8.0)" in debian/libgtp6.shlibs in osmo-ggsn.git
also do the soname check using abipkgdiff/pkg-abidiff
shlibs is the older brute-force mechanism, there is also the newer one based on symbols,
where things that use a library get a depends on the version of the library that has all
the symbols that they use.
thats more complicated though and means maintaining a list of exported symbols and the
versions they appeared in
the symbols stuff has the advantage of more relaxed dependencies for most things using a library
</pre>