Project

General

Profile

Actions

Bug #3060

closed

abis_rsl.c: properly handle a REL_IND from the MS

Added by neels about 6 years ago. Updated over 5 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
03/13/2018
Due date:
% Done:

0%

Spec Reference:

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.

Actions #2

Updated by laforge about 6 years ago

  • Assignee set to 4368
Actions #3

Updated by laforge almost 6 years ago

  • Assignee changed from 4368 to neels
Actions #4

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.

Actions #5

Updated by neels over 5 years ago

  • Status changed from New to Rejected

nonsense.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)