osmo-bsc does not react on RSL RELEASE INDICATION (TC_chan_rel_rll_rel_ind)
See TTCN3 testcase:
When the the RSL RELEASE INDICATION is sent to the BSC the BSC just silently ignores the indication on the RSL layer, however it sends a CLEAR REQUEST on the A-Interface still.
#1 Updated by dexter over 1 year ago
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.
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.
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.
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:
/* * 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;
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
BSSAP.receive(tr_BSSAP_DISC_ind(dt.sccp_conn_id, ?, ?));
The testcase even passes but I get two CLEAR REQUESTS in the trace then, so its still not ok.
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"?
#2 Updated by dexter over 1 year ago
- File trace_with_check.pcapng trace_with_check.pcapng added
- File trace_with_check_removed.pcapng trace_with_check_removed.pcapng added
- % Done changed from 0 to 10
Attached one finds two traches:
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.
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.
#4 Updated by laforge over 1 year ago
I think this is something we could possibly postpone until we have a lchan FSM,
at which point it should be easier.
Our main objective at the moment is to make sure to have good test coverage (and pass
all related tests) on the gsm_subscriber_conn FSM, so we can merge the reltaed branch
without any expected fall-out.
So things like proper handling of all the various different assignments / mode modify and (intra-BSC)
hand-over are higher on the list.