Bug #4819
closed
Wrong RLL ERR IND sent during LAPDm re-establishment procedures
Added by laforge over 3 years ago.
Updated over 3 years ago.
Description
In
#4549 we-ve encountered a situation where a MS (by intention or by accident) sends a SABM with L=0 on a already fully established lchan. This currently triggers:
- an RLL ERROR IND "SABM frame with information not allowed in this state" (cause 14)
- the cause value is even wrong, as there was no information field present ;)
- an UA response (i.e. the re-establishment actually happens
So somehow we send a RLL ERR IND that shouldn't be sent.
- Related to Feature #4549: Emergency Call Priority / Pre-Emption added
we should create a TTCN3 test case as part of BTS_Tests_LAPDm that produces this scenario:
- establish a SDCCH like normal, transmit some data back and forth
- send a SABM with L=0 for SAPI=0 from the MS
- expect that the SABM is responded to with a UA
- expect no RLL ERROR IND on the BTS side. Rather, an "ESTABLISH IND", if at all.
- Subject changed from Wring RLL ERR IND sent during LAPDm re-establishment procedures to Wrong RLL ERR IND sent during LAPDm re-establishment procedures
the test should also verify that any L3 messages sent in uplink after the SABM/UA exchange are passed to the Abis/RSL side
On Mon, Oct 19, 2020 at 06:22:32PM +0000, pespin [REDMINE] wrote:
However it's not triggering the issue seen in #4549 because lapdm state in BTS is not LAPD_STATE_TIMER_RECOV as in the initial case, but LAPD_STATE_MF_EST.
I think the TIMER_RECOV state just means there is some un-acknowledged data,
so if you send an I-frame from the Abis/RSL side, which has not yet been acknowledged
from the Um/L1CTL side (after T200 expiration, which is certainly < 1s), you should be in that state.
- Status changed from New to Feedback
- % Done changed from 0 to 90
- Status changed from Feedback to Resolved
- % Done changed from 90 to 100
Merged, and I also confirm the bug is fixed with a real modem.
Also available in: Atom
PDF
