Project

General

Profile

Bug #4819

Wrong RLL ERR IND sent during LAPDm re-establishment procedures

Added by laforge 4 months ago. Updated 4 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
libosmogsm
Target version:
-
Start date:
10/19/2020
Due date:
% Done:

100%

Spec Reference:

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 issues

Related to OsmoBSC - Feature #4549: Emergency Call Priority / Pre-EmptionFeedback05/12/2020

Associated revisions

Revision 76190d30 (diff)
Added by pespin 4 months ago

lapdm: Allow SABM L=0 in Timer Recovery State

3GPP TS 44.006 8.6.3 "Procedures for re-establishment" is quite
explicit:
"""
When the data link layer receives in the multiple frame established state
or !!!timer recovery state!!! a DL-ESTABLISH- REQUEST primitive from layer
3 or an SABM (with L=0), the normal establishment procedure of sub-clause
8.4.1.2 shall be initiated.
"""

If L>0 in that state, send a DM as stated in 8.4.1.2:
"""
If the data link layer entity is unable to enter the multiple-frame-established
state, it shall respond to the SABM command with a DM response with the F bit
set to the same binary value as the P bit in the received SABM command.
"""

Related: OS#4549
Related: OS#4819
Change-Id: I7959dc39f883cd5c56c36a21176a2401838d7b62

History

#1 Updated by laforge 4 months ago

  • Related to Feature #4549: Emergency Call Priority / Pre-Emption added

#2 Updated by laforge 4 months ago

  • Assignee set to pespin
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.

#3 Updated by laforge 4 months ago

  • Subject changed from Wring RLL ERR IND sent during LAPDm re-establishment procedures to Wrong RLL ERR IND sent during LAPDm re-establishment procedures

#4 Updated by laforge 4 months ago

the test should also verify that any L3 messages sent in uplink after the SABM/UA exchange are passed to the Abis/RSL side

#5 Updated by pespin 4 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 4 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 4 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

#8 Updated by pespin 4 months ago

  • 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

Add picture from clipboard (Maximum size: 48.8 MB)