Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-02-28T00:28:49ZOpen Source Mobile Communications
Redmine OsmoBSC - Bug #6378 (New): Ericsson DUG 20 rejects SI2quaterhttps://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> OsmoBSC - Bug #6324 (New): Making a data call results in B0RKEN lchanshttps://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> OsmoBSC - Bug #5986 (New): PAGING impossible until CCCH LOAD IND is received from the BTShttps://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> OsmoBTS - Bug #5944 (In Progress): DTXu + AMR on TCH/H appears to be not usable on osmo-bts-sysmohttps://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 #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> 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> OsmoPCU - Feature #5833 (New): A "meas-feed" for osmo-pcuhttps://osmocom.org/issues/58332022-12-18T18:32:10Zkeith
<p>It might be interesting to observe real-time display of some parameters available from the PCU;<br />such as:</p>
<ul>
<li>RSSI </li>
<li>Link Quality</li>
<li>Coding Scheme</li>
<li>DL Throughput.</li>
</ul>
<p>This could be integrated into the "meas web" app<sup><a href="#fn1">1</a></sup>.</p>
<p>[1] <a class="external" href="https://gitlab.tic-ac.org/keith/meas_web">https://gitlab.tic-ac.org/keith/meas_web</a></p> OsmoBSC - Feature #5740 (New): Disallow unworkable AMR modes.https://osmocom.org/issues/57402022-11-03T19:21:01Zkeith
<p>This is fairly trivial, but as a note to self, two things.</p>
<p>1) establish exactly what's wrong and make it not possible to configure osmo-bsc like this?<br />2) Can "RADIO INTERFACE MESSAGE FAILURE" be any more sepcific? (LOG / Tx to MSC)</p>
<p>config:<br /><pre>
amr tch-h modes 2 3 4 5
amr tch-h threshold ms 32 24 32
amr tch-h hysteresis ms 8 4 4
amr tch-h threshold bts 32 24 32
amr tch-h hysteresis bts 8 4 4
amr tch-h start-mode 3
</pre></p>
<pre>
Radio Signalling Link (RSL)
GSM A-I/F DTAP - Assignment Command
Protocol Discriminator: Radio Resources Management messages (6)
DTAP Radio Resources Management Message Type: Assignment Command (0x2e)
Channel Description 2 - Description of the First Channel, after time
Power Command
Channel Mode - Mode of the First Channel(Channel Set 1)
Element ID: 0x63
Channel Mode: speech full rate or half rate version 3(FR AMR or HR AMR) (65)
MultiRate configuration
Element ID: 0x03
Length: 6
001. .... = Multirate speech version: Adaptive Multirate speech version 1 (1)
...0 .... = NSCB: Noise Suppression Control Bit: Noise Suppression can be used (default) (0)
.... 1... = ICMI: Initial Codec Mode Indicator: The initial codec mode is defined by the Start Mode field (1)
.... ..10 = Start Mode: 2
0... .... = 12,2 kbit/s codec rate: is not part of the subset
.0.. .... = 10,2 kbit/s codec rate: is not part of the subset
..1. .... = 7,95 kbit/s codec rate: is part of the subset
...1 .... = 7,40 kbit/s codec rate: is part of the subset
.... 1... = 6,70 kbit/s codec rate: is part of the subset
.... .1.. = 5,90 kbit/s codec rate: is part of the subset
.... ..0. = 5,15 kbit/s codec rate: is not part of the subset
.... ...0 = 4,75 kbit/s codec rate: is not part of the subset
..10 0000 = AMR Threshold: 16.0 dB (32)
1000 .... = AMR Hysteresis: 4.0 dB (8)
.... 0110 00.. .... = AMR Threshold: 12.0 dB (24)
..01 00.. = AMR Hysteresis: 2.0 dB (4)
.... ..10 0000 .... = AMR Threshold: 16.0 dB (32)
.... 0100 = AMR Hysteresis: 2.0 dB (4)
</pre>
<pre>
GSM A-I/F DTAP - Assignment Failure
Protocol Discriminator: Radio Resources Management messages (6)
DTAP Radio Resources Management Message Type: Assignment Failure (0x2f)
RR Cause
RR cause value: Channel mode unacceptable (9)
</pre>
<pre>
20221103200919685 DCHAN DEBUG lchan(3-0-1-SDCCH8-0)[0x55b6c3e79310]{ESTABLISHED}: (type=SDCCH) SAPI=0 DATA INDICATION (abis_rsl.c:2528)
20221103200919685 DCHAN DEBUG lchan(3-0-1-SDCCH8-0)[0x55b6c3e79310]{ESTABLISHED}: (type=SDCCH) Rx ASSIGNMENT FAILURE (gsm_04_08_rr.c:985)
20221103200919685 DAS DEBUG assignment(msc0-conn16_subscr-IMSI-334070000000890-TMSI-0x11dc2226_3-0-2-TCH_H-0)[0x55b6c3e91b40]{WAIT_RR_ASS_COMPLETE}: Received Event ASSIGNMENT_EV_RR_ASSIGNMENT_FAIL (gsm_04_08_rr.c:1031)
20221103200919685 DAS DEBUG assignment(msc0-conn16_subscr-IMSI-334070000000890-TMSI-0x11dc2226_3-0-2-TCH_H-0)[0x55b6c3e91b40]{WAIT_RR_ASS_COMPLETE}: (bts=3,trx=0,ts=2,ss=0) incrementing rate counter: assignment:failed Received Assignment Failure message (assignment_fsm.c:738)
20221103200919685 DAS DEBUG assignment(msc0-conn16_subscr-IMSI-334070000000890-TMSI-0x11dc2226_3-0-2-TCH_H-0)[0x55b6c3e91b40]{WAIT_RR_ASS_COMPLETE}: (bts=3,trx=0,ts=2,ss=0) incrementing rate counter: bts3 assignment:failed_speech Received Assignment Failure message on speech lchan (assignment_fsm.c:738)
20221103200919685 DAS ERROR assignment(msc0-conn16_subscr-IMSI-334070000000890-TMSI-0x11dc2226_3-0-2-TCH_H-0)[0x55b6c3e91b40]{WAIT_RR_ASS_COMPLETE}: (bts=3,trx=0,ts=2,ss=0) Assignment failed in state WAIT_RR_ASS_COMPLETE, cause RADIO INTERFACE MESSAGE FAILURE: Rx RR Assignment Failure (assignment_fsm.c:739)
20221103200919685 DAS DEBUG assignment(msc0-conn16_subscr-IMSI-334070000000890-TMSI-0x11dc2226_3-0-2-TCH_H-0)[0x55b6c3e91b40]{WAIT_RR_ASS_COMPLETE}: (bts=3,trx=0,ts=2,ss=0) result rate counter already recorded, NOT counting as: assignment:error Assignment failed for other reason (assignment_fsm.c:739)
20221103200919685 DMSC INFO Tx MSC: BSSMAP: ASSIGNMENT FAIL (osmo_bsc_sigtran.c:380)
</pre> OsmoSGSN - Bug #5725 (Resolved): Assert failed mm->gb.mm_state_fsm->state != ST_MM_IDLE sgsn_libg...https://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 #5712 (New): LCLS FSM; Not possible to get out from NO_LONGER_LShttps://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> OsmoBSC - Feature #5586 (New): Ericsson RBS could recover Unlocked state without osmo-bsc restarthttps://osmocom.org/issues/55862022-06-21T22:23:37Zkeith
<p>It seems something can happen and we get into a Administrative Locked state.</p>
<p>I'm not sure if there may be a way to fully reset all FSMs and restart the BTS with some vty commands, but even if there is, this requires manual intervention.</p>
<p>Maybe there is some way we could automatically re-trigger a full FSM reset and reinitialisation in the case that we see something like whatever happened in this log snippet at Jun 21 15:17:28</p>
<p>In this case there was nothing to do other than restart osmo-msc anyway, as all TRX were Locked.</p>
<pre>
Jun 21 15:16:46 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: call (re-)establishment (ra=0x45, neci=0x01, chreq_reason=0x02)
Jun 21 15:16:46 huautla-bsc osmo-bsc[12475]: DCHAN ERROR abis_rsl.c:1257 lchan(0-1-7-TCH_F-0)[0x5637f32cef60]{WAIT_RF_RELEASE_ACK}: (type=TCH_F) CONNECTION FAIL (cause=Remote Transco
Jun 21 15:16:48 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:623 -> ASSIGNMENT COMMAND tch_mode=0x01
Jun 21 15:16:50 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 2 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:16:51 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: call (re-)establishment (ra=0x4d, neci=0x01, chreq_reason=0x02)
Jun 21 15:16:51 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: answer to paging (ra=0x82, neci=0x01, chreq_reason=0x01)
Jun 21 15:16:52 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: call (re-)establishment (ra=0x43, neci=0x01, chreq_reason=0x02)
Jun 21 15:16:52 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:623 -> ASSIGNMENT COMMAND tch_mode=0x01
Jun 21 15:16:52 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:623 -> ASSIGNMENT COMMAND tch_mode=0x01
Jun 21 15:16:53 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: other (ra=0x1a, neci=0x01, chreq_reason=0x04)
Jun 21 15:16:53 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: other (ra=0x13, neci=0x01, chreq_reason=0x04)
Jun 21 15:16:55 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 0 Type: 2 RR-Cause: 0x0 'Normal event'
Jun 21 15:16:55 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: call (re-)establishment (ra=0x4f, neci=0x01, chreq_reason=0x02)
Jun 21 15:16:56 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: Location updating (ra=0x0c, neci=0x01, chreq_reason=0x03)
Jun 21 15:16:56 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:623 -> ASSIGNMENT COMMAND tch_mode=0x01
Jun 21 15:16:57 huautla-bsc osmo-bsc[12475]: DCHAN ERROR abis_rsl.c:1257 lchan(0-1-6-TCH_F-0)[0x5637f32cd1c0]{WAIT_BEFORE_RF_RELEASE}: (type=TCH_F) CONNECTION FAIL (cause=Remote Tran
Jun 21 15:16:57 huautla-bsc osmo-bsc[12475]: DLMGCP ERROR mgcp_client_fsm.c:281 MGCP_CONN(to-MSC)[0x5637f33996a0]{ST_CRCX_RESP}: MGW/CRCX: response yields error: 540 FAIL
Jun 21 15:16:57 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: answer to paging (ra=0x89, neci=0x01, chreq_reason=0x01)
Jun 21 15:16:57 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 4 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:16:58 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 2 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:16:58 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: Location updating (ra=0x09, neci=0x01, chreq_reason=0x03)
Jun 21 15:16:59 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: answer to paging (ra=0x9d, neci=0x01, chreq_reason=0x01)
Jun 21 15:16:59 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:623 -> ASSIGNMENT COMMAND tch_mode=0x01
Jun 21 15:16:59 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: other (ra=0x16, neci=0x01, chreq_reason=0x04)
Jun 21 15:16:59 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 2 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:00 huautla-bsc osmo-bsc[12475]: DCHAN ERROR abis_rsl.c:2494 lchan(0-2-3-SDCCH8-1)[0x5637f32cab50]{ESTABLISHED}: (type=SDCCH) ERROR INDICATION cause=Timer T200 expired (N
Jun 21 15:17:01 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 3 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:01 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: other (ra=0x1f, neci=0x01, chreq_reason=0x04)
Jun 21 15:17:01 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: Location updating (ra=0x06, neci=0x01, chreq_reason=0x03)
Jun 21 15:17:02 huautla-bsc osmo-bsc[12475]: DAS ERROR assignment_fsm.c:984 assignment(msc0-conn104282_subscr-IMSI-334020509263036-TMSI-0x67cc9114_0-3-7-TCH_F-0)[0x5637f341f770]{WAIT
Jun 21 15:17:02 huautla-bsc osmo-bsc[12475]: DAS ERROR assignment_fsm.c:162 assignment(msc0-conn104282_subscr-IMSI-334020509263036-TMSI-0x67cc9114_0-3-7-TCH_F-0)[0x5637f341f770]{WAIT
Jun 21 15:17:02 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 1 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:02 huautla-bsc osmo-bsc[12475]: DCHAN ERROR abis_rsl.c:2494 lchan(0-3-0-SDCCH8-0)[0x5637f32c3df0]{ESTABLISHED}: (type=SDCCH) ERROR INDICATION cause=Timer T200 expired (N
Jun 21 15:17:02 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 0 Type: 2 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:03 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 0 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:03 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(67) greater than 63
Jun 21 15:17:03 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 2 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:03 huautla-bsc osmo-bsc[12475]: DCHAN ERROR abis_rsl.c:1257 lchan(0-1-2-TCH_F-0)[0x5637f32c91c0]{ESTABLISHED}: (type=TCH_F) CONNECTION FAIL (cause=Remote Transcoder Fail
Jun 21 15:17:03 huautla-bsc osmo-bsc[12475]: DMSC ERROR osmo_bsc_bssap.c:1284 SUBSCR_CONN(msc0-conn104284_subscr-IMSI-334020437435608-TMSI-0x7343ead6)[0x5637f33decc0]{WAIT_CLEAR_CMD}
Jun 21 15:17:03 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 0 Type: 2 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:04 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 0 Type: 2 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:04 huautla-bsc osmo-bsc[12475]: DCHAN ERROR abis_rsl.c:2494 lchan(0-3-0-SDCCH8-0)[0x5637f32c3df0]{WAIT_BEFORE_RF_RELEASE}: (type=SDCCH) ERROR INDICATION cause=Timer T200
Jun 21 15:17:04 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: other (ra=0x10, neci=0x01, chreq_reason=0x04)
Jun 21 15:17:04 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(67) greater than 63
Jun 21 15:17:04 huautla-bsc osmo-bsc[12475]: DCHAN ERROR abis_rsl.c:1257 lchan(0-2-7-TCH_F-0)[0x5637f32ced20]{WAIT_BEFORE_RF_RELEASE}: (type=TCH_F) CONNECTION FAIL (cause=Remote Tran
Jun 21 15:17:05 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(66) greater than 63
Jun 21 15:17:05 huautla-bsc osmo-bsc[12475]: DCHAN ERROR abis_rsl.c:1257 lchan(0-3-6-TCH_F-0)[0x5637f32cd910]{WAIT_BEFORE_RF_RELEASE}: (type=TCH_F) CONNECTION FAIL (cause=Remote Tran
Jun 21 15:17:06 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 4 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:06 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(67) greater than 63
Jun 21 15:17:06 huautla-bsc osmo-bsc[12475]: DCHAN ERROR abis_rsl.c:2494 lchan(0-2-3-SDCCH8-4)[0x5637f32c9020]{ESTABLISHED}: (type=SDCCH) ERROR INDICATION cause=Timer T200 expired (N
Jun 21 15:17:06 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: answer to paging (ra=0x84, neci=0x01, chreq_reason=0x01)
Jun 21 15:17:07 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(67) greater than 63
Jun 21 15:17:08 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: call (re-)establishment (ra=0x45, neci=0x01, chreq_reason=0x02)
Jun 21 15:17:08 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 0 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:08 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(67) greater than 63
Jun 21 15:17:08 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 0 Type: 2 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:08 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 0 Type: 2 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:09 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:623 -> ASSIGNMENT COMMAND tch_mode=0x01
Jun 21 15:17:09 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(67) greater than 63
Jun 21 15:17:10 huautla-bsc osmo-bsc[12475]: DCHAN ERROR abis_rsl.c:1257 lchan(0-1-4-TCH_F-0)[0x5637f32cb980]{WAIT_BEFORE_RF_RELEASE}: (type=TCH_F) CONNECTION FAIL (cause=Remote Tran
Jun 21 15:17:10 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(67) greater than 63
Jun 21 15:17:11 huautla-bsc osmo-bsc[12475]: DAS ERROR assignment_fsm.c:737 assignment(msc0-conn104292_subscr-IMSI-334020349378157-TMSI-0x20694a35_0-3-7-TCH_F-0)[0x5637f33321d0]{WAIT
Jun 21 15:17:11 huautla-bsc osmo-bsc[12475]: DAS ERROR assignment_fsm.c:162 assignment(msc0-conn104292_subscr-IMSI-334020349378157-TMSI-0x20694a35_0-3-7-TCH_F-0)[0x5637f33321d0]{WAIT
Jun 21 15:17:11 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 1 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:12 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: other (ra=0x16, neci=0x01, chreq_reason=0x04)
Jun 21 15:17:13 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: other (ra=0x17, neci=0x01, chreq_reason=0x04)
Jun 21 15:17:17 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(66) greater than 63
Jun 21 15:17:17 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: other (ra=0x14, neci=0x01, chreq_reason=0x04)
Jun 21 15:17:18 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(66) greater than 63
Jun 21 15:17:18 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 0 Type: 2 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:18 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: answer to paging (ra=0x92, neci=0x01, chreq_reason=0x01)
Jun 21 15:17:19 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 0 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:19 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(67) greater than 63
Jun 21 15:17:19 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: answer to paging (ra=0x89, neci=0x01, chreq_reason=0x01)
Jun 21 15:17:19 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: call (re-)establishment (ra=0x43, neci=0x01, chreq_reason=0x02)
Jun 21 15:17:19 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 1 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:20 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 2 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:20 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(67) greater than 63
Jun 21 15:17:20 huautla-bsc osmo-bsc[12475]: DCHAN ERROR abis_rsl.c:1257 lchan(0-1-5-TCH_F-0)[0x5637f32ccaa0]{WAIT_BEFORE_RF_RELEASE}: (type=TCH_F) CONNECTION FAIL (cause=Remote Tran
Jun 21 15:17:20 huautla-bsc osmo-bsc[12475]: DCHAN ERROR abis_rsl.c:1257 lchan(0-3-2-TCH_F-0)[0x5637f32c9500]{WAIT_BEFORE_RF_RELEASE}: (type=TCH_F) CONNECTION FAIL (cause=Remote Tran
Jun 21 15:17:20 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 3 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:21 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(67) greater than 63
Jun 21 15:17:21 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:623 -> ASSIGNMENT COMMAND tch_mode=0x01
Jun 21 15:17:21 huautla-bsc osmo-bsc[12475]: DLMGCP ERROR mgcp_client_fsm.c:281 MGCP_CONN(to-MSC)[0x5637f32d5330]{ST_CRCX_RESP}: MGW/CRCX: response yields error: 540 FAIL
Jun 21 15:17:21 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: Location updating (ra=0x04, neci=0x01, chreq_reason=0x03)
Jun 21 15:17:22 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: other (ra=0x16, neci=0x01, chreq_reason=0x04)
Jun 21 15:17:22 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(67) greater than 63
Jun 21 15:17:23 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(67) greater than 63
Jun 21 15:17:24 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1923 (bts=0) Ignoring CHAN RQD: Access Delay(66) greater than 63
Jun 21 15:17:25 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: call (re-)establishment (ra=0x40, neci=0x01, chreq_reason=0x02)
Jun 21 15:17:25 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: call (re-)establishment (ra=0x4f, neci=0x01, chreq_reason=0x02)
Jun 21 15:17:26 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: answer to paging (ra=0x92, neci=0x01, chreq_reason=0x01)
Jun 21 15:17:26 huautla-bsc osmo-bsc[12475]: DAS ERROR assignment_fsm.c:984 assignment(msc0-conn104298_subscr-IMSI-334020534773701-TMSI-0x41be1d16_0-3-7-TCH_F-0)[0x5637f3337310]{WAIT
Jun 21 15:17:26 huautla-bsc osmo-bsc[12475]: DAS ERROR assignment_fsm.c:162 assignment(msc0-conn104298_subscr-IMSI-334020534773701-TMSI-0x41be1d16_0-3-7-TCH_F-0)[0x5637f3337310]{WAIT
Jun 21 15:17:28 huautla-bsc osmo-bsc[12475]: DLMGCP ERROR mgcp_client_endpoint_fsm.c:626 Invalid MGW endpoint request: no ci
Jun 21 15:17:28 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: other (ra=0x1f, neci=0x01, chreq_reason=0x04)
Jun 21 15:17:28 huautla-bsc osmo-bsc[12475]: DNM DEBUG bts_ericsson_rbs2000.c:120 inp_sig_cb(): Input signal 'TEI-UP' received
Jun 21 15:17:28 huautla-bsc osmo-bsc[12475]: DRSL NOTICE osmo_bsc_main.c:322 (bts=0,trx=0) bootstrapping RSL on ARFCN 247 using MCC-MNC 334-07 LAC=274 CID=100 BSIC=63
Jun 21 15:17:28 huautla-bsc osmo-bsc[12475]: DRR INFO system_information.c:725 Serving cell: 241 245 247 251
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR INFO system_information.c:725 SI2 Neighbour cells in same band: 249
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR INFO system_information.c:725 SI5 Neighbour cells in same band: 249
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI1: 55 06 19 8e 78 8a 20 00 00 00 00 00 00 00 00 00 00 00 00 e5 04 00 6b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI2: 59 06 1a 8e 7c 80 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI2bis: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI2ter: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI2quater: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI3: 49 06 1b 00 64 33 f4 70 01 12 c8 03 05 27 43 40 e5 04 00 29 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI4: 31 06 1c 33 f4 70 01 12 43 40 e5 04 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI5: 06 1d 9e 7c 80 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5bis: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5ter: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI6: 06 1e 00 64 33 f4 70 01 12 27 ff 3b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-0-0-CCCH)[0x5637f3295b20]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-0-1-SDCCH8)[0x5637f32962a0]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-0-2-SDCCH8)[0x5637f3296aa0]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-0-3-TCH_F)[0x5637f32972a0]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-0-4-TCH_F)[0x5637f3297aa0]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-0-5-TCH_F)[0x5637f3298330]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-0-6-TCH_F)[0x5637f3298bc0]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-0-7-TCH_F)[0x5637f3299450]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=3,ts=3,ss=0): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DCHAN ERROR lchan_fsm.c:1803 lchan(0-3-7-TCH_F-0)[0x5637f32cf2a0]{WAIT_RF_RELEASE_ACK}: (type=TCH_F) lchan failure in state WAIT_RF_RELEA
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=2,ts=3,ss=0): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=3,ts=0,ss=4): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: call (re-)establishment (ra=0x46, neci=0x01, chreq_reason=0x02)
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=2,ts=3,ss=1): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=3,ts=4,ss=0): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRSL INFO abis_rsl.c:1932 (bts=0) CHAN RQD: reason: other (ra=0x18, neci=0x01, chreq_reason=0x04)
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=3,ts=0,ss=5): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=3,ts=5,ss=0): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DCHAN ERROR abis_rsl.c:2494 lchan(0-3-0-SDCCH8-6)[0x5637f32c7c20]{ESTABLISHED}: (type=SDCCH) ERROR INDICATION cause=Timer T200 expired (N
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 6 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=3,ts=0,ss=1): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG gsm_04_08_rr.c:329 Sending Channel Release: Chan: Number: 2 Type: 1 RR-Cause: 0x0 'Normal event'
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=3,ts=0,ss=2): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DNM DEBUG bts_ericsson_rbs2000.c:120 inp_sig_cb(): Input signal 'TEI-UP' received
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRSL NOTICE osmo_bsc_main.c:322 (bts=0,trx=3) bootstrapping RSL on ARFCN 245 using MCC-MNC 334-07 LAC=274 CID=100 BSIC=63
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR INFO system_information.c:725 SI5 Neighbour cells in same band: 249
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI5: 06 1d 9e 7c 80 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5bis: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5ter: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI6: 06 1e 00 64 33 f4 70 01 12 27 ff 3b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-0-SDCCH8)[0x5637f32abeb0]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-1-TCH_F)[0x5637f32ac330]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-2-TCH_F)[0x5637f32acb30]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-3-TCH_F)[0x5637f32ad330]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-4-TCH_F)[0x5637f32adb30]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-5-TCH_F)[0x5637f32ae330]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-6-TCH_F)[0x5637f32aeb30]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-7-TCH_F)[0x5637f32af3c0]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DNM DEBUG bts_ericsson_rbs2000.c:120 inp_sig_cb(): Input signal 'TEI-UP' received
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRSL NOTICE osmo_bsc_main.c:322 (bts=0,trx=3) bootstrapping RSL on ARFCN 245 using MCC-MNC 334-07 LAC=274 CID=100 BSIC=63
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR INFO system_information.c:725 SI5 Neighbour cells in same band: 249
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI5: 06 1d 9e 7c 80 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5bis: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5ter: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI6: 06 1e 00 64 33 f4 70 01 12 27 ff 3b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-0-SDCCH8)[0x5637f32abeb0]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-1-TCH_F)[0x5637f32ac330]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-2-TCH_F)[0x5637f32acb30]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-3-TCH_F)[0x5637f32ad330]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-4-TCH_F)[0x5637f32adb30]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-5-TCH_F)[0x5637f32ae330]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-6-TCH_F)[0x5637f32aeb30]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-7-TCH_F)[0x5637f32af3c0]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=3,ts=4,ss=0): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DNM DEBUG bts_ericsson_rbs2000.c:120 inp_sig_cb(): Input signal 'TEI-UP' received
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRSL NOTICE osmo_bsc_main.c:322 (bts=0,trx=2) bootstrapping RSL on ARFCN 251 using MCC-MNC 334-07 LAC=274 CID=100 BSIC=63
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR INFO system_information.c:725 SI5 Neighbour cells in same band: 249
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI5: 06 1d 9e 7c 80 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5bis: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5ter: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI6: 06 1e 00 64 33 f4 70 01 12 27 ff 3b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-0-SDCCH8)[0x5637f32a53a0]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-1-SDCCH8)[0x5637f32a5820]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-2-SDCCH8)[0x5637f32a6020]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-3-SDCCH8)[0x5637f32a6820]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-4-TCH_F)[0x5637f32a7020]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-5-TCH_F)[0x5637f32a7820]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-6-TCH_F)[0x5637f32a8020]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-7-TCH_F)[0x5637f32a88b0]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=3,ts=0,ss=2): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DNM DEBUG bts_ericsson_rbs2000.c:120 inp_sig_cb(): Input signal 'TEI-UP' received
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRSL NOTICE osmo_bsc_main.c:322 (bts=0,trx=2) bootstrapping RSL on ARFCN 251 using MCC-MNC 334-07 LAC=274 CID=100 BSIC=63
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR INFO system_information.c:725 SI5 Neighbour cells in same band: 249
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI5: 06 1d 9e 7c 80 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5bis: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5ter: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI6: 06 1e 00 64 33 f4 70 01 12 27 ff 3b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-0-SDCCH8)[0x5637f32a53a0]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-1-SDCCH8)[0x5637f32a5820]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-2-SDCCH8)[0x5637f32a6020]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-3-SDCCH8)[0x5637f32a6820]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-4-TCH_F)[0x5637f32a7020]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-5-TCH_F)[0x5637f32a7820]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-6-TCH_F)[0x5637f32a8020]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-7-TCH_F)[0x5637f32a88b0]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=3,ts=1,ss=0): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=3,ts=0,ss=4): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=3,ts=0,ss=5): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DNM DEBUG bts_ericsson_rbs2000.c:120 inp_sig_cb(): Input signal 'TEI-UP' received
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRSL NOTICE osmo_bsc_main.c:322 (bts=0,trx=2) bootstrapping RSL on ARFCN 251 using MCC-MNC 334-07 LAC=274 CID=100 BSIC=63
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR INFO system_information.c:725 SI5 Neighbour cells in same band: 249
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI5: 06 1d 9e 7c 80 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5bis: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5ter: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI6: 06 1e 00 64 33 f4 70 01 12 27 ff 3b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-0-SDCCH8)[0x5637f32a53a0]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-1-SDCCH8)[0x5637f32a5820]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-2-SDCCH8)[0x5637f32a6020]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-3-SDCCH8)[0x5637f32a6820]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-4-TCH_F)[0x5637f32a7020]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-5-TCH_F)[0x5637f32a7820]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-6-TCH_F)[0x5637f32a8020]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-7-TCH_F)[0x5637f32a88b0]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=3,ts=0,ss=1): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DNM DEBUG bts_ericsson_rbs2000.c:120 inp_sig_cb(): Input signal 'TEI-UP' received
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRSL NOTICE osmo_bsc_main.c:322 (bts=0,trx=2) bootstrapping RSL on ARFCN 251 using MCC-MNC 334-07 LAC=274 CID=100 BSIC=63
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR INFO system_information.c:725 SI5 Neighbour cells in same band: 249
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI5: 06 1d 9e 7c 80 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5bis: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5ter: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI6: 06 1e 00 64 33 f4 70 01 12 27 ff 3b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-0-SDCCH8)[0x5637f32a53a0]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-1-SDCCH8)[0x5637f32a5820]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-2-SDCCH8)[0x5637f32a6020]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-3-SDCCH8)[0x5637f32a6820]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-4-TCH_F)[0x5637f32a7020]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-5-TCH_F)[0x5637f32a7820]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-6-TCH_F)[0x5637f32a8020]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-2-7-TCH_F)[0x5637f32a88b0]{UNUSED}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLGLOBAL ERROR write_queue.c:127 wqueue(0x5637f2460180) is full. Rejecting msgb
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DMEAS ERROR meas_feed.c:88 meas_feed (bts=0,trx=3,ts=0,ss=3): sending measurement report failed
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DNM DEBUG bts_ericsson_rbs2000.c:120 inp_sig_cb(): Input signal 'TEI-UP' received
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DNM NOTICE bts_ericsson_rbs2000.c:47 bootstrapping OML for TRX 0/2
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=2) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=2) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=2) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DNM DEBUG bts_ericsson_rbs2000.c:120 inp_sig_cb(): Input signal 'TEI-UP' received
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DNM NOTICE bts_ericsson_rbs2000.c:47 bootstrapping OML for TRX 0/2
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=2) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=2) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DNM DEBUG bts_ericsson_rbs2000.c:120 inp_sig_cb(): Input signal 'TEI-UP' received
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRSL NOTICE osmo_bsc_main.c:322 (bts=0,trx=3) bootstrapping RSL on ARFCN 245 using MCC-MNC 334-07 LAC=274 CID=100 BSIC=63
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR INFO system_information.c:725 SI5 Neighbour cells in same band: 249
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI5: 06 1d 9e 7c 80 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5bis: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5ter: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI6: 06 1e 00 64 33 f4 70 01 12 27 ff 3b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-0-SDCCH8)[0x5637f32abeb0]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-1-TCH_F)[0x5637f32ac330]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-2-TCH_F)[0x5637f32acb30]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-3-TCH_F)[0x5637f32ad330]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-4-TCH_F)[0x5637f32adb30]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-5-TCH_F)[0x5637f32ae330]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-6-TCH_F)[0x5637f32aeb30]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-7-TCH_F)[0x5637f32af3c0]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DNM DEBUG bts_ericsson_rbs2000.c:120 inp_sig_cb(): Input signal 'TEI-UP' received
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRSL NOTICE osmo_bsc_main.c:322 (bts=0,trx=3) bootstrapping RSL on ARFCN 245 using MCC-MNC 334-07 LAC=274 CID=100 BSIC=63
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR INFO system_information.c:725 SI5 Neighbour cells in same band: 249
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI5: 06 1d 9e 7c 80 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5bis: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:355 SI5ter: OFF
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DRR DEBUG bts_trx.c:353 SI6: 06 1e 00 64 33 f4 70 01 12 27 ff 3b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-0-SDCCH8)[0x5637f32abeb0]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-1-TCH_F)[0x5637f32ac330]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-2-TCH_F)[0x5637f32acb30]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-3-TCH_F)[0x5637f32ad330]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-4-TCH_F)[0x5637f32adb30]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-5-TCH_F)[0x5637f32ae330]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-6-TCH_F)[0x5637f32aeb30]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DTS ERROR osmo_bsc_main.c:359 timeslot(0-3-7-TCH_F)[0x5637f32af3c0]{IN_USE}: Event TS_EV_RSL_READY not permitted
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=2) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=2) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=1) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=2) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=2) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=2) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=0) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=1) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=2) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=3) discarding RSL message received in locked administrative state
Jun 21 15:17:29 huautla-bsc osmo-bsc[12475]: DLMI ERROR e1_config.c:133 (bts=0,trx=0) discarding RSL message received in locked administrative state
</pre> Ericsson RBS 6xxx - Bug #5571 (New): DUG can come up, but with Avail: "Power Off"https://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 #5491 (New): MT CSFB calls fail (only) first time after Airplane mode toggle (proba...https://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://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://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://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://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> Ericsson RBS 6xxx - Feature #5307 (New): Support for Multiple Sectors at an RBS site.https://osmocom.org/issues/53072021-11-13T20:20:54Zkeith
<p>The question came up at a recent OsmoDevCall.</p>
<ul>
<li>Osmo-BSC is lacking support to run more than one BTS on a DUG.</li>
<li>There are "workarounds", involving having more than one DUG/E1 but this is extra power comsumption, plus quite a "waste" of Hardware, consider having three DUGs for a 3 sector site, when 1 can theoretically do it.</li>
</ul>
<ul>
<li>I wonder might it be possible to run two osmo-bsc instances communicating with the same DUG over distinct E1 ports. (The iceE1 has potential for two ports.) Or for the time being, by using two iceE1?</li>
</ul> OsmoBSC - Bug #5246 (New): sigsegv in bts_count_free_ts()https://osmocom.org/issues/52462021-10-03T20:08:51Zkeith
<p>Just noting this quickly, I'll need to come back to it.</p>
<pre>
Program received signal SIGSEGV, Segmentation fault.
0x00005555555b5535 in bts_count_free_ts (bts=0x0, pchan=GSM_PCHAN_TCH_F) at bts.c:725
725 llist_for_each_entry(trx, &bts->trx_list, list)
(gdb) bt
#0 0x00005555555b5535 in bts_count_free_ts (bts=0x0, pchan=GSM_PCHAN_TCH_F)
at bts.c:725
#1 0x00005555555dd4bc in candidate_set_free_tch (c=0x7fffffff7a50)
at handover_decision_2.c:1026
#2 0x00005555555ddb0e in collect_handover_candidate (lchan=0x7ffff7fd1ef0,
nmp=0x7ffff7fd205c, clist=0x7fffffff87e0, candidates=0x7fffffff87dc,
include_weaker_rxlev=false, rxlev_current=53, neighbors_count=0x7fffffff8764)
at handover_decision_2.c:1141
#3 0x00005555555de410 in collect_candidates_for_lchan (lchan=0x7ffff7fd1ef0,
clist=0x7fffffff87e0, candidates=0x7fffffff87dc, _rxlev_current=0x7fffffffce60,
include_weaker_rxlev=false) at handover_decision_2.c:1219
#4 0x00005555555de569 in find_alternative_lchan (lchan=0x7ffff7fd1ef0,
include_weaker_rxlev=false, request_upgrade_to_tch_f=false)
at handover_decision_2.c:1298
#5 0x00005555555e0729 in on_measurement_report (mr=0x7ffff7fd2230)
at handover_decision_2.c:1572
#6 0x00005555555f0f05 in ho_meas_rep (mr=0x7ffff7fd2230) at handover_logic.c:95
#7 0x00005555555f3242 in ho_logic_sig_cb (subsys=3, signal=8, handler_data=0x0,
signal_data=0x7fffffffd060) at handover_logic.c:316
</pre> OsmoBSC - Bug #5190 (New): segfault with osmo-e1dhttps://osmocom.org/issues/51902021-07-01T20:14:59Zkeith
<ul>
<li>The e1 hardware becomes unresponsive.. (why?) [soft reboot does not help]</li>
<li>osmo-e1d starts but has no interface</li>
<li>osmo-bsc crashes.</li>
</ul>
<pre>
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7e8abf0 in e1d_line_update (line=0x555555948af0) at input/e1d.c:370
370 input/e1d.c: No such file or directory.
(gdb) bt
#0 0x00007ffff7e8abf0 in e1d_line_update (line=0x555555948af0) at input/e1d.c:370
#1 0x00007ffff7e84e7c in e1inp_line_update (line=0x555555948af0) at e1_input.c:929
#2 0x00005555555bc3d8 in ?? ()
#3 0x00005555555737ea in ?? ()
#4 0x00007ffff7c6409b in __libc_start_main (main=0x555555573050, argc=1, argv=0x7fffffffe5f8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffffffe5e8) at ../csu/libc-start.c:308
#5 0x000055555557408a in ?? ()
(gdb) quit
A debugging session is active.
Inferior 1 [process 2230] will be killed.
Quit anyway? (y or n) y
root@tosepan:/etc/osmocom# lsusb
Bus 001 Device 002: ID 8087:8000 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
</pre> OsmoSTP - Bug #5186 (Resolved): local-ip config parameter can cause unclear behaviour on dual IP ...https://osmocom.org/issues/51862021-06-18T20:44:28Zkeith
<p><em>keyphrase from osmo-bsc log for search engines:</em></p>
<pre>
DLSS7 ERROR m3ua.c:507 XUA_AS(as-clnt-A-0-m3ua) {AS_DOWN}: Event AS-TRANSFER.req not permitted
</pre>
<p>In osmo-stp.cfg we have typically have something like:</p>
<pre>
cs7 instance 0
xua rkm routing-key-allocation dynamic-permitted
route-table system
listen m3ua 2905
local-ip ::
accept-asp-connections dynamic-permitted
</pre>
<p>This is actually fine.</p>
<p>But, the configuration VTY tells us:</p>
<pre>
OsmoSTP(config-cs7-listen)# local-ip
A.B.C.D IPv4 Address to use for XUA
X:X::X:X IPv6 Address to use for XUA
</pre>
<p>and so the user might think, ah OK I want to use 127.0.0.1 resulting in a config of</p>
<pre>
cs7 instance 0
xua rkm routing-key-allocation dynamic-permitted
route-table system
listen m3ua 2905
local-ip 127.0.0.1
accept-asp-connections dynamic-permitted
</pre>
<p>Actually local-ip 0.0.0.0 will also trigger this issue.</p>
<p>Now let's start osmo-bsc and osmo-msc with the minimal configuration files needed to start up, leaving the rest to default values for the sake of clarify here, although this issue can be observed with a fully configured BSC/MSC:</p>
<p><strong>osmo-bsc.cfg:</strong><br /><pre>
msc 0
mgw remote-ip 127.0.0.1
</pre></p>
<p><strong>osmo-msc.cfg:</strong><br />BLANK - Use all defaults.</p>
<p>osmo-bsc will constantly log: Event AS-TRANSFER.req not permitted</p>
<p>although osmo-bsc vty will show:</p>
<pre>
OsmoBSC# show msc
0 m3ua RI=SSN_PC,PC=0.23.3,SSN=BSSAP RI=SSN_PC,PC=0.23.1,SSN=BSSAP
</pre>
<p>osmo-msc vty will show:<br /><pre>
OsmoMSC# show bsc
OsmoMSC#
</pre></p>
<p>So one should <strong>NOT</strong> use an ipv4 address in local-ip, <strong>UNLESS</strong> ipv6 stack is disabled with:</p>
<pre>
sysctl net.ipv6.conf.all.disable_ipv6=1
</pre>
<p>If you have OSMO-STP config with an IPv4 address in local-ip, as soon as you disable the ipv6 stack, you'll see:<br /><pre>
[other log messages leading up to...]
DMSC NOTICE (msc0) BSSMAP assocation is up
</pre></p>
<p>To confirm:</p>
<p>with <strong>local-ip ::</strong></p>
<p>there's no problem with ipv4/ipv6 being enabled or not.</p> OsmoBSC - Feature #5156 (New): Support intraBSC handover between distinct BTS typeshttps://osmocom.org/issues/51562021-05-14T23:08:01Zkeith
<p>If we handover from a osmo-bts (RTP) type to an E1 BTS, WE don't create a new MGCP endpoint for the E1 lchan,</p>
<p>As far as I can make out nor do we assign any endpoint to the lchan.</p>
<p>in lchan_rtp_fsm where we would deal with changing the endpoints for handover:</p>
<pre><code>if (!is_ipaccess_bts(lchan->ts->trx->bts)) {<br /> LOG_LCHAN_RTP(lchan, LOGL_DEBUG, "Audio link to-BTS via E1, skipping IPACC\n");<br /> lchan_rtp_fsm_state_chg(LCHAN_RTP_ST_READY);<br /> return;<br /> }</code></pre> OsmoBSC - Feature #4922 (In Progress): Implement MS Power Controlhttps://osmocom.org/issues/49222020-12-24T17:17:30Zkeith
<p>For a BTS that does not implement MS uplink power control, such as the RBS6k, we need to have the BSC process MEASUREMENT RESULT messages and send MS POWER CONTROL messages.</p> OsmoMSC - Bug #4863 (New): T3212 is unclear in config/vtyhttps://osmocom.org/issues/48632020-11-19T00:37:08Zkeith
<p>In the config file or vty the command timer vlr T3212 accepts a value in minutes.</p>
<p>Inline help suggest that this is a "3GPP compliant timer number", However timer 3212 is expressed in units of 6 minutes.</p> libosmo-abis - Feature #4860 (New): Implement separation of line/TEI/datalinks in E1 pcaphttps://osmocom.org/issues/48602020-11-12T17:54:46Zkeith
<p>From gerrit comment by <a class="user active" href="https://osmocom.org/users/7">laforge</a> on <a class="external" href="https://gerrit.osmocom.org/c/libosmo-abis/+/21118">https://gerrit.osmocom.org/c/libosmo-abis/+/21118</a> :</p>
<p>Actually, the fact that we only have a single pcap file for potentially multiple lines is a problem.</p>
<p>Classic pcap files do not offer a way to annotate each packet with information on which interface it was received, so you cannot distinguish traffic from multiple lines.</p>
<p>We need to address this in a generic way. <br />Ideally generating pcap-ng with interface descriptions, or by moving pcap generation to "per line".</p>
<p>But even a single line can contain multiple TEI / datalinks, and you want to somehow separate those.</p> OsmoSGSN - Bug #4824 (Resolved): vty comand "show sndcp" can cause SEGV in vty_dump_sne()https://osmocom.org/issues/48242020-10-21T15:11:06Zkeith
<pre>
(gdb) bt
#0 vty_dump_sne (vty=0x558339e52010, sne=0x558339e57360) at gprs_sndcp_vty.c:44
#1 0x000055833916afb7 in show_sndcp (self=0x55833939aac0 <show_sndcp_cmd>, vty=0x558339e52010, argc=0, argv=0x7ffcb165cf50) at gprs_sndcp_vty.c:60
</pre> OsmoSGSN - Bug #4820 (Resolved): gsn_restart is created in CWDhttps://osmocom.org/issues/48202020-10-19T15:46:28Zkeith
<p>Similar to osmo-msc issue <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: sms.db is created in cwd, which from systemd's point of view is / (Closed)" href="https://osmocom.org/issues/4735">#4735</a>, cwd is / when run from systemd, so we get gsn_restart file created in the system root.</p> OsmoBTS - Bug #4474 (In Progress): l1fwd (-remote) tried to read eeprom locally https://osmocom.org/issues/44742020-03-30T15:37:42Zkeith
<p>THe EEPROM device file is defined in two places:</p>
<pre><code>src/osmo-bts-sysmo/eeprom.c:82:#define EEPROM_DEV "/sys/bus/i2c/devices/i2c-1/1-0050/eeprom"</code></pre>
<p>and </p>
<pre><code>src/osmo-bts-sysmo/misc/sysmobts_par.c:40:#define EEPROM_PATH "/sys/devices/platform/i2c_davinci.1/i2c-1/1-0050/eeprom"</code></pre>
<p>This of course results in errors reading the eeprom, model number band support and calibration tables, that cause osmo-bts-sysmo-remote to error thus:</p>
<pre><code>eeprom fopen: No such file or directory<br /> l1_if.c:1636 Failed to read from EEPROM.</code></pre>
<p>We need some conditional DEFINEs to fix this?</p> osmo-sip-connector - Bug #4352 (New): Need to handle 401 Unauthorized https://osmocom.org/issues/43522020-01-09T09:36:24Zkeith
<p>It was noticed through a misconfiguration of upstream PBX at congress that osmo-sip-connector does not handle a 401 response from upstream.</p>
<p>In this case the upstream was responding with a 401 to our BYE.</p>
<p>osmo-sip-connector just terminates it's own leg anyway, leaving the other leg hanging. <br />granted, there's not a lot to be done from our side if upstream SIP stubbornly refuses to hang up, but we should probably handle this (what do RFCs say?) and indeed have some kind of credential system in osmo-sip-connector.</p> OsmoSGSN - Bug #3964 (New): SIGSEGV in sndcp_sm_deactivate_ind()https://osmocom.org/issues/39642019-04-29T08:41:30Zkeith
<pre>
(gdb) bt
#0 0x000055555556989c in sndcp_sm_deactivate_ind (lle=0x358, nsapi=5 '\005') at gprs_sndcp.c:507
#1 0x000055555556703c in sgsn_pdp_ctx_terminate (pdp=0x5555559a3d00) at gprs_sgsn.c:445
#2 0x0000555555566ac9 in sgsn_mm_ctx_cleanup_free (mm=0x55555591f5e0) at gprs_sgsn.c:337
#3 0x000055555555d658 in mm_ctx_cleanup_free (ctx=0x55555591f5e0, log_text=0x555555589416 "T3350") at gprs_gmm.c:326
#4 0x0000555555562d45 in mmctx_timer_cb (_mm=0x55555591f5e0) at gprs_gmm.c:2156
#5 0x00007ffff7308526 in osmo_timers_update () at timer.c:257
#6 0x00007ffff7308d9a in osmo_select_main (polling=0) at select.c:260
#7 0x0000555555572d21 in main (argc=1, argv=0x7fffffffe618) at sgsn_main.c:524
</pre>
<p>Log leading up to this:</p>
<pre>
DMM NOTICE <0002> gprs_gmm.c:2155 MM(334020160307203/f05ed185) T3350 expired >= 5 times
DMM INFO <0002> gprs_gmm.c:319 MM(334020160307203/f05ed185) Cleaning MM context due to T3350
DMM NOTICE <0002> gprs_sgsn.c:336 MM(334020160307203/f05ed185) Dropping PDP context for NSAPI=5
DGPRS INFO <000e> gprs_sgsn.c:441 PDP(334020160307203/0) Forcing release of PDP context
</pre>
<p>in sgsn_pdp_ctx_terminate<br /><pre>
(gdb) print pdp->mm->gb.llme
$7 = (struct gprs_llc_llme *) 0x0
</pre></p> osmo-sip-connector - Bug #3763 (New): Implement correct handling for call answered elsewherehttps://osmocom.org/issues/37632019-01-22T13:03:13Zkeith
<p>A SIP originated bridged call may be answered elsewhere, then the SIP UA should CANCEL the leg to sip-connector with Reason: SIP;cause=200;text="Call completed elsewhere"</p>
<p>We should handle this and signal the MS to not display a "missed call"</p>
<p>note to self: Need to look up again where I read about this signalling.</p> OsmoBTS - Bug #2942 (New): osmo-bts-virtual+virtphy+mobile paging for SMS delivery failshttps://osmocom.org/issues/29422018-02-13T17:05:36Zkeith
<p>This might be related to osmocom-bb, virtphy more than osmo-bts-virtual</p>
<p>When I send SMS to the virtual mobile, I'm always getting TC1* from gsm0411_smc. <br />USSD service and calling works fine, but when it's SMS, it seems that mobile is waiting for something from the network.</p>
<p>While this is ongoing, 'show ms' in the phone VTY will give:<br />MS 'A' is up, MM connection active<br /> [...snip...]<br /> radio ressource layer state: dedicated<br /> mobility management layer state: wait for network command</p>
<p>Sometimes it works, in fact it was, by chance eventually successful in the trace attached.</p>
<p>If other logging facilities would help from the VTYs, or any other similar procedure pcap, I can supply of course.</p>