Project

General

Profile

Bug #2917

osmo-bsc does not react on RSL RELEASE INDICATION (TC_chan_rel_rll_rel_ind)

Added by dexter 3 months ago. Updated 2 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
02/09/2018
Due date:
% Done:

100%

Spec Reference:

Description

See TTCN3 testcase:
BSC_Tests.TC_chan_rel_rll_rel_ind (fails)

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.

trace_with_check_removed.pcapng (3.58 KB) dexter, 02/09/2018 04:59 PM

trace_with_check.pcapng (4.06 KB) dexter, 02/09/2018 04:59 PM

History

#1 Updated by dexter 3 months 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, ?, ?));

with

    BSSAP.receive(tr_BSSAP_DATA_ind(dt.sccp_conn_id, tr_BSSMAP_ClearRequest));

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 3 months ago

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.
trace_with_check.pcapng

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.
trace_with_check_removed.pcapng

#3 Updated by dexter 3 months ago

  • Status changed from New to Feedback
  • Assignee set to laforge

#4 Updated by laforge 3 months 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.

#5 Updated by dexter 3 months ago

  • Subject changed from osmo-bsc does not react on RSL RELEASE INDICATION to osmo-bsc does not react on RSL RELEASE INDICATION (TC_chan_rel_rll_rel_ind)
  • Status changed from Feedback to Stalled
  • Assignee changed from laforge to dexter

#6 Updated by laforge 3 months ago

  • Project changed from OpenBSC to OsmoBSC

#7 Updated by laforge 2 months ago

  • Status changed from Stalled to Resolved
  • % Done changed from 10 to 100

test now passes after fsm branch was merged.

Also available in: Atom PDF