Bug #3252
closedosmo-bts-sysmo: lapdm issues during phone call establishment
100%
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
Related issues
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
Updated by pespin almost 6 years ago
- Related to Bug #2370: OsmoBTS accepts SAPI!=0 for LAPDm contention resolution added
Updated by pespin almost 6 years ago
Add log with "logging level llapd debug" enabled while running the same scenario.
Updated by laforge almost 6 years ago
On Wed, May 09, 2018 at 11:15:16AM +0000, pespin [REDMINE] wrote:
the correct course of action is then:Seems related to this patch merged recently:
- 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.
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.
Updated by laforge almost 6 years ago
- % Done changed from 0 to 10
- 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.
Updated by laforge almost 6 years ago
- % Done changed from 10 to 60
https://gerrit.osmocom.org/8087 is a proposed fix
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.
Updated by laforge almost 6 years ago
- Status changed from In Progress to Resolved
- % Done changed from 60 to 100
patch long merged