Project

General

Profile

Actions
Copy link

Bug #3252

closed

osmo-bts-sysmo: lapdm issues during phone call establishment

Added by pespin almost 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
laforge
Category:
-
Target version:
-
Start date:
05/09/2018
Due date:
% Done:

100%

Spec Reference:
Tags:
TTCN3

Description

Using sysmobts with 201705-nightly, which contains latest master. Last commits in libosmocore contain some lapdm related commits.

libosmocore Version: 0.11.0+gitr1+f1bdf781ac-r0.
osmo-bts Version: 0.11.0+gitr1+f1bdf781ac-r0.

I'm running a complete core network in my sysmobts. I have 2 MS registered with the core network. I try to call from one MS to another one. Phone call starts in MO but finishes after a few seconds. Nothing shows ups in MT.

I attach the pcap trace taken in the sysmobts while placing the call, and the osmo-bts-sysmo with gsmtap enabled and following log categories enabled:

  logging level rsl info
  logging level oml info
  logging level rll notice
  logging level rr notice
  logging level meas notice
  logging level pag info
  logging level l1c info
  logging level l1p info
  logging level dsp info
  logging level abis notice

gsmtap enabled catgories:

 gsmtap-sapi bcch
 gsmtap-sapi ccch
 gsmtap-sapi rach
 gsmtap-sapi agch
 gsmtap-sapi pch
 gsmtap-sapi sdcch
 gsmtap-sapi tch/f
 gsmtap-sapi tch/h
 gsmtap-sapi pacch
 gsmtap-sapi pdtch
 gsmtap-sapi ptcch
 gsmtap-sapi cbch
 gsmtap-sapi sacch

There seems to be some issues in lapdm during paging command:

May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0007> ../../../git/src/common/l1sap.c:1119 099398/74/00/50/18 Rx TCH.ind chan_nr=0x09
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0000> ../../../git/src/common/rsl.c:2620 (bts=0,trx=0,ts=0,ss=0) Rx RSL PAGING_CMD
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0005> ../../../git/src/common/paging.c:225 Add paging to queue (group=4, queue_len=1)
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0007> ../../../git/src/common/l1sap.c:1119 099402/74/04/03/22 Rx TCH.ind chan_nr=0x09
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0000> ../../../git/src/common/rsl.c:2567 (bts=0,trx=0,ts=0,ss=1) Handing RLL msg UNIT_DATA_IND from LAPDm to MEAS REP
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0007> ../../../git/src/common/l1sap.c:1119 099406/74/08/07/26 Rx TCH.ind chan_nr=0x09
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0007> ../../../git/src/common/l1sap.c:1119 099411/74/13/12/31 Rx TCH.ind chan_nr=0x09
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0007> ../../../git/src/common/l1sap.c:1119 099415/74/17/16/35 Rx TCH.ind chan_nr=0x09
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0007> ../../../git/src/common/l1sap.c:1119 099419/74/21/20/39 Rx TCH.ind chan_nr=0x09
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0007> ../../../git/src/common/l1sap.c:1119 099424/74/00/25/44 Rx TCH.ind chan_nr=0x09
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0007> ../../../git/src/common/l1sap.c:1119 099428/74/04/29/48 Rx TCH.ind chan_nr=0x09
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0007> ../../../git/src/common/l1sap.c:1119 099432/74/08/33/00 Rx TCH.ind chan_nr=0x09
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0007> ../../../git/src/common/l1sap.c:1119 099437/74/13/38/05 Rx TCH.ind chan_nr=0x09
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0007> ../../../git/src/common/l1sap.c:1119 099441/74/17/42/09 Rx TCH.ind chan_nr=0x09
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0011> ../../../git/src/gsm/lapdm.c:715 received message not permitted<0011> ../../../git/src/gsm/lapdm.c:419 sending MDL-ERROR-IND 8
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0000> ../../../git/src/common/rsl.c:2590 (bts=0,trx=0,ts=1,ss=0) Fwd RLL msg ERROR_IND from LAPDm to A-bis
May 09 10:25:31 sysmobts-v2 osmo-bts-sysmo[1276]: <0007> ../../../git/src/common/l1sap.c:1119 099450/75/00/00/18 Rx TCH.ind chan_nr=0x09

which corresponds to frame 185-193 in the pcap trace.

Files

lapdm_error_during_call_setup-osmo-bts-symo.log lapdm_error_during_call_setup-osmo-bts-symo.log 93.6 KB pespin, 05/09/2018 10:39 AM
lapdm_error_during_call_setup.pcapng lapdm_error_during_call_setup.pcapng 136 KB pespin, 05/09/2018 10:39 AM
osmo-bts-sysmo_llapd_debug.log osmo-bts-sysmo_llapd_debug.log 62.5 KB pespin, 05/09/2018 11:31 AM

Related issues

Related to OsmoBTS - Bug #2370: OsmoBTS accepts SAPI!=0 for LAPDm contention resolutionResolvedlaforge07/17/2017

Actions
Actions
Copy link
 #1

Updated by pespin almost 6 years ago

Seems related to this patch merged recently:

commit 1284c3e96170b1622106097e944e07354549bb2e
Author: Harald Welte <laforge@gnumonks.org>
Date:   Tue May 1 18:11:02 2018 +0200

    lapdm: Implement SABM related constraints

    * MO SAPI0 establishment *must always* have L3 payload for contention
      resolution
    * SAPI3 establishment *must never* use contention resolution
    * MT establish must never use contention resolution

    Change-Id: I8c2c103cdc7f9a45d7b2080c572f559fc3db58e4
    Closes: OS#2370

Actions
Copy link
 #2

Updated by pespin almost 6 years ago

  • Related to Bug #2370: OsmoBTS accepts SAPI!=0 for LAPDm contention resolution added
Actions
Copy link
 #3

Updated by pespin almost 6 years ago

Add log with "logging level llapd debug" enabled while running the same scenario.

Actions
Copy link
 #4

Updated by pespin almost 6 years ago

  • Assignee changed from 4368 to laforge
Actions
Copy link
 #5

Updated by laforge almost 6 years ago

On Wed, May 09, 2018 at 11:15:16AM +0000, pespin [REDMINE] wrote:

Seems related to this patch merged recently:

the correct course of action is then:
  • revert the patch in question
  • if possible, try to implement a (TTCN or other) test case that
    "passes" before the patch and fails with the patch

Basically it shows us that the test coverage before merging this patch
was apparently insufficient, otherwise the merginf o the patch should
have broken some test case.

Actions
Copy link
 #6

Updated by laforge almost 6 years ago

  • Status changed from New to In Progress

The MS is sending a SABM frame with no L3 payload on FACCH at SAPI0. According to my understanding of the specs, that's illegal. Rather, the MS must always use the contention resolution procedure?

I'll re-read the specs.

Actions
Copy link
 #7

Updated by laforge almost 6 years ago

  • % Done changed from 0 to 10
ok, the diffrence is whether we establish the LAPDm link
  • after RACH + IMM.ASS (we must include L3 payload for contention resolution)
  • after assignment from one channel to another (we must not include L3 payload)
    • probably handover is also the same as assignment here.
Actions
Copy link
 #8

Updated by laforge almost 6 years ago

  • % Done changed from 10 to 60
Actions
Copy link
 #9

Updated by laforge almost 6 years ago

patch merged. I'll try to work on related tests in BTS_Tests.ttcn as soon as I find time.

Actions
Copy link
 #10

Updated by laforge almost 6 years ago

  • Tags set to TTCN3
Actions
Copy link
 #11

Updated by laforge almost 6 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 60 to 100

patch long merged

Actions
Copy link

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)