https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092021-03-26T22:39:15ZOpen Source Mobile CommunicationsOsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=217532021-03-26T22:39:15Zkeith
<ul><li><strong>File</strong> <a href="/attachments/4603">bsc-e1.pcap</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4603/bsc-e1.pcap">bsc-e1.pcap</a> added</li></ul><p>bsc-e1.pcap starts shortly after bring up, to all chans being in BORKEN state</p>
<p>Nack filter: gsm_abis_rsl.msg_type == 0x23</p> OsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=217542021-03-26T22:40:05Zkeith
<ul><li><strong>File</strong> <a href="/attachments/4604">osmo-bsc.cfg</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4604/osmo-bsc.cfg">osmo-bsc.cfg</a> added</li></ul><p>osmo-bsc Config.</p> OsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=217622021-03-27T22:35:25Zkeith
<ul></ul><p>For what it may be worth, simply transitioning to WAIT_RF_RELEASE_ACK instead of BORKEN does seem to eventually return the state to UNUSED and allows further use of the channels.</p>
<pre><code class="c syntaxhl"><span class="o">---</span> <span class="n">a</span><span class="o">/</span><span class="n">src</span><span class="o">/</span><span class="n">osmo</span><span class="o">-</span><span class="n">bsc</span><span class="o">/</span><span class="n">lchan_fsm</span><span class="p">.</span><span class="n">c</span>
<span class="o">+++</span> <span class="n">b</span><span class="o">/</span><span class="n">src</span><span class="o">/</span><span class="n">osmo</span><span class="o">-</span><span class="n">bsc</span><span class="o">/</span><span class="n">lchan_fsm</span><span class="p">.</span><span class="n">c</span>
<span class="err">@@</span> <span class="o">-</span><span class="mi">730</span><span class="p">,</span><span class="mi">7</span> <span class="o">+</span><span class="mi">730</span><span class="p">,</span><span class="mi">7</span> <span class="err">@@</span> <span class="k">static</span> <span class="kt">void</span> <span class="nf">lchan_fsm_wait_activ_ack</span><span class="p">(</span><span class="k">struct</span> <span class="n">osmo_fsm_inst</span> <span class="o">*</span><span class="n">fi</span><span class="p">,</span> <span class="kt">uint32_t</span> <span class="n">event</span><span class="p">,</span> <span class="n">v</span>
<span class="n">lchan</span><span class="o">-></span><span class="n">release</span><span class="p">.</span><span class="n">rr_cause</span> <span class="o">=</span> <span class="n">bsc_gsm48_rr_cause_from_rsl_cause</span><span class="p">(</span><span class="n">lchan</span><span class="o">-></span><span class="n">release</span><span class="p">.</span><span class="n">rsl_error_cause</span><span class="p">);</span>
<span class="n">lchan</span><span class="o">-></span><span class="n">release</span><span class="p">.</span><span class="n">in_error</span> <span class="o">=</span> <span class="nb">true</span><span class="p">;</span>
<span class="k">if</span> <span class="p">(</span><span class="n">lchan</span><span class="o">-></span><span class="n">release</span><span class="p">.</span><span class="n">rsl_error_cause</span> <span class="o">!=</span> <span class="n">RSL_ERR_RCH_ALR_ACTV_ALLOC</span><span class="p">)</span>
<span class="o">-</span> <span class="n">next_state</span> <span class="o">=</span> <span class="n">LCHAN_ST_BORKEN</span><span class="p">;</span>
<span class="o">+</span> <span class="n">next_state</span> <span class="o">=</span> <span class="n">LCHAN_ST_WAIT_RF_RELEASE_ACK</span><span class="p">;</span>
<span class="k">else</span>
<span class="cm">/* Taking this over from legacy code: send an RF Chan Release even though
* the Activ was NACKed. Is this really correct? */</span>
</code></pre> OsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=217632021-03-28T02:25:43Zfixeria
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li></ul><p>I had a look at the capture file, and I think I know what happens:</p>
<ul>
<li>from time to time the BSC gets CHANnel ReQuireD with <em>Access Delay</em> 65 (!)
<ul>
<li>the usual range is 0 .. 63, and 65 * 550 m == 35.8 km is quite far...</li>
<li>AFAIR, values exceeding this range are allowed for GSM-450 only</li>
</ul>
</li>
<li>osmo-bsc tries to allocate a channel by sending RSL CHANnel ACTIVation message
<ul>
<li>this message contains the Timing Advance IE with the expected delay</li>
<li>apparently, your BTS is not happy about such a huge delay</li>
</ul>
</li>
<li>the BTS rejects RSL CHANnel ACTIVation by sending NACK</li>
<li>osmo-bsc gets confused and treats the timeslot as 'BROKEN'</li>
</ul>
<p>In osmo-bts we have configurable filtering for the delay / quality of the Access and Normal bursts, so 'outsiders' never reach the BSC. And I guess you need to configure / implement something similar for your Ericsson BTS. I have no idea if this BTS itself can do filtering, but in the worst case we can implement it in osmo-bsc.</p>
<p>Feel free to cherry-pick this patch and give it a try:</p>
<p><a class="external" href="https://git.osmocom.org/osmo-bsc/commit/?h=fixeria/rach&id=f2d3cddef982c0c8592b9b4e5ef4089a1910ea3c">https://git.osmocom.org/osmo-bsc/commit/?h=fixeria/rach&id=f2d3cddef982c0c8592b9b4e5ef4089a1910ea3c</a></p> OsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=217712021-03-28T19:34:08Zkeith
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>In Progress</i></li></ul><p>Nice, I tested your patch adding a log line and certainly can see it happening from time to time, however, changing the MNC and bringing up the network again with 1,000s of phones then attempting to LUR, I still end up with most if not all BORKEN SDCCH after a few minutes.</p>
<p>What other information would help?</p> OsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=217722021-03-28T19:50:52Zlaforge
<ul></ul><p>fixeria wrote:</p>
<blockquote>
<p>I had a look at the capture file, and I think I know what happens:</p>
</blockquote>
<p>thanks for the debugging.</p>
<blockquote>
<ul>
<li>from time to time the BSC gets CHANnel ReQuireD with <em>Access Delay</em> 65 (!)
<ul>
<li>the usual range is 0 .. 63, and 65 * 550 m == 35.8 km is quite far...</li>
<li>AFAIR, values exceeding this range are allowed for GSM-450 only</li>
</ul>
</li>
<li>osmo-bsc tries to allocate a channel by sending RSL CHANnel ACTIVation message
<ul>
<li>this message contains the Timing Advance IE with the expected delay</li>
<li>apparently, your BTS is not happy about such a huge delay</li>
</ul></li>
</ul>
</blockquote>
<p>I think the assignment of "extended range" timing advance is something that likely requires additional [proprietary] siganling. We don't need to bother as we don't want to implement it.</p>
<blockquote>
<ul>
<li>the BTS rejects RSL CHANnel ACTIVation by sending NACK</li>
<li>osmo-bsc gets confused and treats the timeslot as 'BROKEN'</li>
</ul>
</blockquote>
<p>osmo-bsc should for sure not get confused by a CHAN ACT NACK, is there a separate bug here?</p>
<blockquote>
<p>In osmo-bts we have configurable filtering for the delay / quality of the Access and Normal bursts, so 'outsiders' never reach the BSC. And I guess you need to configure / implement something similar for your Ericsson BTS. I have no idea if this BTS itself can do filtering, but in the worst case we can implement it in osmo-bsc.</p>
</blockquote>
<p>I think osmo-bsc should do a proper check, let's call it "input validation". It should be done generically so it will work for any type of BTS.</p> OsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=217732021-03-28T19:57:30Zlaforge
<ul></ul><p>keith wrote:</p>
<blockquote>
<p>What other information would help?</p>
</blockquote>
<p>if this fix worked as expected, the log+pcap should now look quite different. please update, thanks!</p> OsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=217742021-03-28T19:58:06Zkeith
<ul><li><strong>File</strong> <a href="/attachments/4614">lur-bomb.pcap</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4614/lur-bomb.pcap">lur-bomb.pcap</a> added</li></ul><p>So looking at the original pcap again, I see that, as you rightly spotted, all those Nacks are indeed the results of TA > 63 - so looks like that patch is a runner. Should I prepare this, with associated vty config? rach-max-ta or some such?</p>
<p>Adding a pcap of bringing the network up with a new MNC..</p>
<p>I left it run a little longer just now, and interestingly it's only on TRX 0 that everything gets b0rked:<br /><pre>
OsmoBSC# show lchan summary
BTS 0, TRX 0, Timeslot 1 SDCCH8, Lchan 0, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8, Lchan 1, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8, Lchan 2, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8, Lchan 3, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8, Lchan 4, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8, Lchan 5, Type SDCCH, State WAIT_ACTIV_ACK - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8, Lchan 6, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8, Lchan 7, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 2 SDCCH8, Lchan 0, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 2 SDCCH8, Lchan 1, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 2 SDCCH8, Lchan 2, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 2 SDCCH8, Lchan 3, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 2 SDCCH8, Lchan 4, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 2 SDCCH8, Lchan 5, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 2 SDCCH8, Lchan 6, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 2 SDCCH8, Lchan 7, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 3 TCH/F, Lchan 0, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 4 TCH/F, Lchan 0, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 5 TCH/F, Lchan 0, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 6 TCH/F, Lchan 0, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 7 TCH/F, Lchan 0, Type NONE, State BORKEN - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 0 SDCCH8, Lchan 0, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 0 SDCCH8, Lchan 1, Type SDCCH, State WAIT_AFTER_ERROR - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 0 SDCCH8, Lchan 2, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 0 SDCCH8, Lchan 3, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 0 SDCCH8, Lchan 4, Type SDCCH, State WAIT_AFTER_ERROR - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 0 SDCCH8, Lchan 5, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 0 SDCCH8, Lchan 6, Type SDCCH, State WAIT_AFTER_ERROR - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 0 SDCCH8, Lchan 7, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 1 SDCCH8, Lchan 0, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 1 SDCCH8, Lchan 1, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 1 SDCCH8, Lchan 2, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 1 SDCCH8, Lchan 3, Type SDCCH, State WAIT_AFTER_ERROR - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 1 SDCCH8, Lchan 4, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 1 SDCCH8, Lchan 5, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 1 SDCCH8, Lchan 6, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 1 SDCCH8, Lchan 7, Type SDCCH, State WAIT_AFTER_ERROR - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 2 TCH/F, Lchan 0, Type TCH_F, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 3 TCH/F, Lchan 0, Type TCH_F, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 4 TCH/F, Lchan 0, Type TCH_F, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 5 TCH/F, Lchan 0, Type TCH_F, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 6 TCH/F, Lchan 0, Type TCH_F, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 1, Timeslot 7 TCH/F, Lchan 0, Type TCH_F, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
</pre></p>
<p>I also see chans actually leaving the and re-entering the borken state, which I thought was not possible. I guess full osmo-bsc log would be a useful thing here. I'm not sure how to deal with the lack of gsmtap logs embedded in the pcap.</p> OsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=217752021-03-28T20:03:31Zkeith
<ul><li><strong>File</strong> <a href="/attachments/4615">osmo-bsc.log.gz</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4615/osmo-bsc.log.gz">osmo-bsc.log.gz</a> added</li></ul><p>Adding a DEBUG level osmo-bsc.log, Maybe grepping on it might help. I just let it run until it was about 100M</p>
<p>[Note this log does not correspond directly to lur-bomb.pcap]</p> OsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=217782021-03-28T23:22:36Zfixeria
<ul></ul><p>Hi keith,</p>
<p>keith wrote:</p>
<blockquote>
<p>So looking at the original pcap again, I see that, as you rightly spotted, all those Nacks are indeed the results of TA > 63 - so looks like that patch is a runner. Should I prepare this, with associated vty config?</p>
</blockquote>
<p>yes, would definitely be nice to get this patch finished and merged.</p>
<blockquote>
<p>rach-max-ta or some such?</p>
</blockquote>
<p>I think "rach max-delay" would be better. In case of the Access Burst we're dealing with <em>delay</em> (in symbol periods), not an <em>advance</em> yet. Regarding the reasonable default value, I think 63 would be safe to assume.</p> OsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=217792021-03-28T23:26:08Zfixeria
<ul></ul><blockquote>
<p>Adding a DEBUG level osmo-bsc.log, Maybe grepping on it might help. I just let it run until it was about 100M</p>
</blockquote>
<p>This time it happens because of a different problem:</p>
<pre>
DCHAN DEBUG <000f> fsm.c:322 lchan(0-0-2-SDCCH8-4)[0x55e1591e21b0]{WAIT_RF_RELEASE_ACK}: Timeout of T3111
DCHAN DEBUG <000f> lchan_fsm.c:1574 lchan(0-0-2-SDCCH8-4)[0x55e1591e21b0]{WAIT_RF_RELEASE_ACK}: (type=SDCCH) Handling failure, will then transition to state BORKEN
DCHAN ERROR <000f> lchan_fsm.c:81 lchan(0-0-2-SDCCH8-4)[0x55e1591e21b0]{WAIT_RF_RELEASE_ACK}: (type=SDCCH) lchan failure in state WAIT_RF_RELEASE_ACK: Timeout
DCHAN DEBUG <000f> lchan_fsm.c:1574 lchan(0-0-2-SDCCH8-4)[0x55e1591e21b0]{WAIT_RF_RELEASE_ACK}: state_chg to BORKEN
DCHAN DEBUG <000f> lchan_fsm.c:382 lchan(0-0-2-SDCCH8-4)[0x55e1591e21b0]{BORKEN}: (type=SDCCH) Clearing lchan state
...
DCHAN DEBUG <000f> abis_rsl.c:1232 lchan(0-0-2-SDCCH8-4)[0x55e1591e21b0]{BORKEN}: (type=NONE) Rx MEAS_RES
DCHAN DEBUG <000f> abis_rsl.c:1096 lchan(0-0-2-SDCCH8-4)[0x55e1591e21b0]{BORKEN}: (type=NONE) MEAS RES for inactive channel
...
DCHAN DEBUG <000f> abis_rsl.c:1232 lchan(0-0-2-SDCCH8-4)[0x55e1591e21b0]{BORKEN}: (type=NONE) Rx RF_CHAN_REL_ACK
DCHAN DEBUG <000f> abis_rsl.c:1264 lchan(0-0-2-SDCCH8-4)[0x55e1591e21b0]{BORKEN}: Received Event LCHAN_EV_RSL_RF_CHAN_REL_ACK
DCHAN DEBUG <000f> lchan_fsm.c:1300 lchan(0-0-2-SDCCH8-4)[0x55e1591e21b0]{BORKEN}: state_chg to WAIT_AFTER_ERROR
</pre>
<p>The value of T3111 appears to be too tight for your setup? Assuming that you're using the default:</p>
<pre>
OsmoBSC# show timer net T3111
net: T3111 = 2 s Wait time before RSL RF Channel Release (default: 2 s)
</pre>
<p>Please try again with a higher value, like 4 or even 8.</p> OsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=217802021-03-28T23:35:50Zfixeria
<ul></ul><p>laforge wrote:</p>
<blockquote><blockquote>
<ul>
<li>the BTS rejects RSL CHANnel ACTIVation by sending NACK</li>
<li>osmo-bsc gets confused and treats the timeslot as 'BROKEN'</li>
</ul>
</blockquote>
<p>osmo-bsc should for sure not get confused by a CHAN ACT NACK, is there a separate bug here?</p>
</blockquote>
<p>TBH, I don't know. The current approach seems to be logical and safe from the FSM point of view. What would probably make sense is some kind of watchdog that would try to un-BORKE BORKen timeslots after a certain time. This can be done by activating a broken sub-slot and releasing it immediately. If the BTS still refuses to activate it, then it's completely BORKen and the second attempt to un-BORKE can be postponed further. What do you think?</p> OsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=218152021-04-02T07:37:39Zkeith
<ul></ul><p>Submitted <a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/23574">https://gerrit.osmocom.org/c/osmo-bsc/+/23574</a></p>
<p>If that flies, re this ticket, I would still like to see the watchdog idea implemented.</p> OsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=218162021-04-02T07:38:01Zkeith
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>50</i></li></ul> OsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=218232021-04-04T20:21:48Zkeith
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-4 priority-4 priority-high2" href="/issues/5106">Feature #5106</a>: Watchdog that would try to un-BORKE BORKen timeslots</i> added</li></ul> OsmoBSC - Bug #5096: rbs2000 ALL BORKEN Channelshttps://projects.osmocom.org/issues/5096?journal_id=218252021-04-04T20:22:20Zkeith
<ul><li><strong>Due date</strong> set to <i>04/04/2021</i></li><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>50</i> to <i>100</i></li></ul><p>Patch merged, resolved.</p>