Bug #4819
Wrong RLL ERR IND sent during LAPDm re-establishment procedures
100%
Description
- 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 issues
History
#1 Updated by laforge 3 months ago
- Related to Feature #4549: Emergency Call Priority / Pre-Emption added
#2 Updated by laforge 3 months ago
- Assignee set to pespin
- 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.
#5 Updated by pespin 3 months ago
Test added here:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20793 bts-lapdm: Introduce test TC_normal_reestablishment
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.
#6 Updated by laforge 3 months ago
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.
#7 Updated by pespin 3 months ago
- Status changed from New to Feedback
- % Done changed from 0 to 90
Bug is reproduced by this test:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20805 bts-lapdm: Introduce test TC_normal_reestablishment_state_unacked
And fixed by (test passes after) this commit:
https://gerrit.osmocom.org/c/libosmocore/+/20807 lapdm: Allow SABM L=0 in Timer Recovery State
