Bug #3060
closedabis_rsl.c: properly handle a REL_IND from the MS
0%
Description
currently our code flattens out the SAPI communicated by a REL IND from the MS, see e.g. abis_rsl.c:2228:
case RSL_MT_REL_IND: /* BTS informs us of having received DISC from MS */ DEBUGPC(DRLL, "RELEASE INDICATION\n"); msg->lchan->sapis[rllh->link_id & 0x7] = LCHAN_SAPI_UNUSED; <--- overridden with zero rll_indication(msg->lchan, rllh->link_id, BSC_RLLR_IND_REL_IND); rsl_handle_release(msg->lchan);
In order to properly detect whether an lchan is completely released or some SAPIs are still active, this needs fixing and a slew of (ttcn3?) tests to verify that it works.
Updated by neels about 6 years ago
see https://gerrit.osmocom.org/7221 (incomplete)
and http://git.osmocom.org/osmo-ttcn3-hacks/commit/?id=27f643639e43a146eab090d723692f47efa452a6 (already merged)
Updated by neels almost 6 years ago
I realize I have misinterpreted this code
msg->lchan->sapis[rllh->link_id & 0x7] = LCHAN_SAPI_UNUSED;
msg->lchan is of course not a part of the received message, but the current lchan state.
We take rllh, the RLL header, and disable only the SAPI indicated by rllh->link_id.
I wonder though why I couldn't get TC_ms_rel_ind_does_not_cause_bssmap_reset() to work,
I dimly remember that I saw direct release without waiting for SAPIs to be released...
another look needs to be taken.