https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092018-02-09T16:55:09ZOpen Source Mobile CommunicationsOsmoBSC - Bug #2917: osmo-bsc does not react on RSL RELEASE INDICATION (TC_chan_rel_rll_rel_ind)https://projects.osmocom.org/issues/2917?journal_id=75592018-02-09T16:55:09Zdexter
<ul></ul><p>I have investigated the problem using my pmaier/fsm branch, but laforge/fsm and probably the current master (i did not check) have a similar problem as well.</p>
<p>See abis_rsl.c:abis_rsl_rx_rll(). The switch-case handles the release indication (case RSL_MT_REL_IND). We can see a call to osmo_fsm_inst_dispatch() this explains why we still get the clear request. From the A-Interface perspective this looks fine. When I get the concept right it is not the business of the GSCON FSM to handle any stuff on the RSL layer it is just inform that a channel was released.</p>
<p>There is also a call to bsc_rll.c:rll_indication(msg->lchan, rllh->link_id, BSC_RLLR_IND_REL_IND) This function iterates throught a list (bsc_rll_reqs), but in this particular case it just does nothing, the list seems to be empty. Maybe this is because there is no link active? I am not sure if this behavior is expected or not.</p>
<p>The call to rsl_handle_release() seems to be more interesting. There it iterates through an array with SAPIs, apparently we need to make sure that all SAPIs are released before we toss the whole channel? When all SAPIs are unused it sets up a timer to make sure that the channel clears. But it does not go into this code section anyway. It immediately bails right at the beginning of the function:</p>
<pre>
/*
* Maybe only one link/SAPI was releasd or the error handling
* was activated. Just return now and let the other code handle
* it.
*/
if (lchan->state != LCHAN_S_REL_REQ)
return;
</pre>
<p>I wonder what this "other code" is. When I remove the If the channel seems to release fine and the TTCN3 testcase comes a little further. When I replace</p>
<pre>
BSSAP.receive(tr_BSSAP_DISC_ind(dt.sccp_conn_id, ?, ?));
</pre>
<p>with</p>
<pre>
BSSAP.receive(tr_BSSAP_DATA_ind(dt.sccp_conn_id, tr_BSSMAP_ClearRequest));
</pre>
<p>The testcase even passes but I get two CLEAR REQUESTS in the trace then, so its still not ok.</p>
<p>I might need some hints to understand this further. What is LCHAN_S_REL_REQ and why are we checking on it? What is or was the "other code"?</p> OsmoBSC - Bug #2917: osmo-bsc does not react on RSL RELEASE INDICATION (TC_chan_rel_rll_rel_ind)https://projects.osmocom.org/issues/2917?journal_id=75602018-02-09T17:01:46Zdexter
<ul><li><strong>File</strong> <a href="/attachments/2924">trace_with_check.pcapng</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/2924/trace_with_check.pcapng">trace_with_check.pcapng</a> added</li><li><strong>File</strong> <a href="/attachments/2923">trace_with_check_removed.pcapng</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/2923/trace_with_check_removed.pcapng">trace_with_check_removed.pcapng</a> added</li><li><strong>% Done</strong> changed from <i>0</i> to <i>10</i></li></ul><p>Attached one finds two traches:</p>
<p>With the current master of pmaier/fsm, the check (lchan->state != LCHAN_S_REL_REQ) is in place. One can clearly see that the RSL RELEASE INDICATION is never answered.<br />trace_with_check.pcapng</p>
<p>The following trace shows the behavior when the check is removed. The channel is released. Everything is looking good except for the two RELEASE REQUESTs on the A-Interface.<br />trace_with_check_removed.pcapng</p> OsmoBSC - Bug #2917: osmo-bsc does not react on RSL RELEASE INDICATION (TC_chan_rel_rll_rel_ind)https://projects.osmocom.org/issues/2917?journal_id=75612018-02-09T17:39:52Zdexter
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li><li><strong>Assignee</strong> set to <i>laforge</i></li></ul> OsmoBSC - Bug #2917: osmo-bsc does not react on RSL RELEASE INDICATION (TC_chan_rel_rll_rel_ind)https://projects.osmocom.org/issues/2917?journal_id=75622018-02-09T19:40:08Zlaforge
<ul></ul><p>I think this is something we could possibly postpone until we have a lchan FSM,<br />at which point it should be easier.</p>
<p>Our main objective at the moment is to make sure to have good test coverage (and pass<br />all related tests) on the gsm_subscriber_conn FSM, so we can merge the reltaed branch<br />without any expected fall-out.</p>
<p>So things like proper handling of all the various different assignments / mode modify and (intra-BSC)<br />hand-over are higher on the list.</p> OsmoBSC - Bug #2917: osmo-bsc does not react on RSL RELEASE INDICATION (TC_chan_rel_rll_rel_ind)https://projects.osmocom.org/issues/2917?journal_id=76542018-02-16T13:02:19Zdexter
<ul><li><strong>Subject</strong> changed from <i>osmo-bsc does not react on RSL RELEASE INDICATION</i> to <i>osmo-bsc does not react on RSL RELEASE INDICATION (TC_chan_rel_rll_rel_ind)</i></li><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Stalled</i></li><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>dexter</i></li></ul> OsmoBSC - Bug #2917: osmo-bsc does not react on RSL RELEASE INDICATION (TC_chan_rel_rll_rel_ind)https://projects.osmocom.org/issues/2917?journal_id=80382018-03-05T19:02:47Zlaforge
<ul><li><strong>Project</strong> changed from <i>OpenBSC</i> to <i>OsmoBSC</i></li></ul> OsmoBSC - Bug #2917: osmo-bsc does not react on RSL RELEASE INDICATION (TC_chan_rel_rll_rel_ind)https://projects.osmocom.org/issues/2917?journal_id=83142018-03-17T20:58:42Zlaforge
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>10</i> to <i>100</i></li></ul><p>test now passes after fsm branch was merged.</p>