Project

General

Profile

Actions
Copy link

Bug #5791

closed

mobile: "DLLAPD NOTICE lapdm.c:769 (dl=0x62c000000ef0) EA bit 0 is not allowed in GSM"

Added by fixeria about 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
fixeria
Category:
OsmocomBB Firmware
Target version:
-
Start date:
11/25/2022
Due date:
% Done:

100%

Resolution:
Spec Reference:

Description

This message is frequently seen when "talking" to an Osmocom based network.

DLLAPD NOTICE lapdm.c:769 (dl=0x62c000000ef0) EA bit 0 is not allowed in GSM
DLLAPD NOTICE lapdm.c:546 (dl=0x62c000000ef0) sending MDL-ERROR-IND 12

mobile originated GSMTAP traces in Wireshark confirm this warning:

$ tshark -r /tmp/lapdm.pcap -Y "(lapdm.ea == 0)" 
    9   1.786785    127.0.0.1 → 127.0.10.1   LAPDm 81 S, func=RR, N(R)=0
   10   2.258601    127.0.0.1 → 127.0.10.1   LAPDm 81 S, func=RR, N(R)=0
   11   2.728325    127.0.0.1 → 127.0.10.1   LAPDm 81 S, func=RR, N(R)=0

$ tshark -r /tmp/lapdm.pcap -Y "(lapdm.ea == 0)" -V | less
GSM TAP Header, ARFCN: 73 (Downlink), TS: 1, Channel: SDCCH/8 (0)
    Version: 2
    Header Length: 16 bytes
    Payload Type: GSM Um (MS<->BTS) (1)
    Time Slot: 1
    ..00 0000 0100 1001 = ARFCN: 73
    .0.. .... .... .... = Uplink: 0
    0... .... .... .... = PCS band indicator: 0
    Signal Level: -47 dBm
    Signal/Noise Ratio: 0 dB
    GSM Frame Number: 1195166
    Channel Type: SDCCH/8 (8)
    Antenna Number: 0
    Sub-Slot: 0
Link Access Procedure, Channel Dm (LAPDm)
    Address Field: 0x0e
        .00. .... = LPD: Normal GSM (0)
        ...0 11.. = SAPI: SMS/SS (3)
        .... ..1. = C/R: 1
        .... ...0 = EA: More octets (0)
    Control field: S, func=RR, N(R)=0 (0x01)
        000. .... = N(R): 0
        .... 00.. = Supervisory frame type: Receiver ready (0x0)
        .... ..01 = Frame type: Supervisory frame (0x1)
    Length Field: 0x03
        0000 00.. = Length: 0
        .... ..1. = M: More segments (1)
        .... ...1 = EL: Final octet (1)

Looks like the S, func=RR frames are encoded incorrectly by the network side? SAPI: SMS/SS (3) is also suspicious.

Related issues

Related to OsmocomBB - Bug #5133: mishandling of the sacch l1 headerResolved04/26/2021

Actions
Actions
Copy link
 #1

Updated by fixeria about 1 year ago

  • % Done changed from 0 to 10

fixeria wrote:

Looks like the S, func=RR frames are encoded incorrectly by the network side? SAPI: SMS/SS (3) is also suspicious.

Actually it's not a coding problem on the network side:

  • I added assert()s to libosmocore checking EA == 1, and osmo-bts did not crash,
  • I was unable to reproduce the problem with trxcon, only with the Calypso PHY,

so it's more likely a problem in osmocom-bb.

Actions
Copy link
 #2

Updated by fixeria about 1 year ago

I attached to mobile with gdb and here is some more insight:

(gdb) bt
#0  rsl_rll_error (cause=cause@entry=12 '\f', mctx=mctx@entry=0x7fffffffd9a0) at ../../../../src/libosmocore/src/gsm/lapdm.c:546
#1  0x00007ffff7822a42 in l2_ph_data_ind (link_id=0 '\000', chan_nr=<optimized out>, le=0x62c000000d60, msg=0x616000013be0)
    at ../../../../src/libosmocore/src/gsm/lapdm.c:819
#2  lapdm_phsap_up (oph=<optimized out>, le=0x62c000000d60) at ../../../../src/libosmocore/src/gsm/lapdm.c:910
#3  0x000055555595d33e in rx_ph_data_ind (msg=0x616000013be0, ms=<optimized out>) at l1ctl.c:340
#4  l1ctl_recv (ms=<optimized out>, msg=msg@entry=0x616000013be0) at l1ctl.c:1002
#5  0x0000555555962a24 in layer2_read (fd=0x62c000000278) at l1l2_interface.c:82
#6  0x00007ffff78c551b in osmo_wqueue_bfd_cb (fd=0x62c000000278, what=1) at ../../../src/libosmocore/src/write_queue.c:47
#7  0x00007ffff78bec40 in poll_disp_fds (n_fd=<optimized out>) at ../../../src/libosmocore/src/select.c:361
#8  _osmo_select_main (polling=polling@entry=0) at ../../../src/libosmocore/src/select.c:399
#9  0x00007ffff78bed1e in osmo_select_main (polling=polling@entry=0) at ../../../src/libosmocore/src/select.c:438
#10 0x00005555557dc627 in main (argc=<optimized out>, argv=<optimized out>) at main.c:277

(gdb) frame 3
#3  0x000055555595d33e in rx_ph_data_ind (msg=0x616000013be0, ms=<optimized out>) at l1ctl.c:340
340             return lapdm_phsap_up(&pp.oph, le);
(gdb) p/s msgb_hexdump(msg)
$13 = 0x7ffff6032684 "[L1]> 41 00 00 49 00 1e 23 de 3f 00 00 00 [L2]> 0e 00 03 03 2d 06 1e 00 00 09 f1 07 00 01 27 ff 2b 2b 2b 2b 2b 2b 2b " 
(gdb) p *(struct l1ctl_info_dl *)msg->l1h
$14 = {chan_nr = 65 'A', link_id = 0 '\000', band_arfcn = 18688, frame_nr = 3726843392, rx_level = 63 '?',
       snr = 0 '\000', num_biterr = 0 '\000', fire_crc = 0 '\000', payload = 0x616000013c98 "\016"}

Looking closely at the output of msgb_hexdump(), I started to understand what's happening:

[L1]> 41 00 00 49 00 1e 23 de 3f 00 00 00
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      struct l1ctl_info_dl

[L2]> 0e 00      03 03    2d 06 1e 00 00 09 f1 07 00 01 27 ff 2b 2b 2b 2b 2b 2b 2b
      ~~~~~      ~~~~~    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      SACCH L1H  LAPDm    SYSTEM INFORMATION TYPE 6 (!)

The layer1 firmware gives us SACCH, but does not mark it as such (link_id = 0). The LAPDm code tries to parse the SACCH L1H as LAODm header, and get confused.

Actions
Copy link
 #3

Updated by fixeria about 1 year ago

  • Category changed from OsmocomBB mobile (host) to OsmocomBB Firmware
  • Status changed from New to In Progress
  • % Done changed from 10 to 80

And here is the reason, in the layer1 firmware (layer1/prim_rx_nb.c):

a955cfd4e (Harald Welte      2010-04-09 21:25:13 +0200 122)             /* Set SACCH indication in Link IDentifier */
a955cfd4e (Harald Welte      2010-04-09 21:25:13 +0200 123)             if (mf_task_flags & MF_F_SACCH)
f4fbafded (Harald Welte      2010-05-29 12:57:48 +0200 124)                     rxnb.dl->link_id = 0x40;
67c49ba66 (Vadim Yanitskiy   2020-03-09 15:42:33 +0700 125)             if (mf_task_flags & MF_F_PTCCH)
67c49ba66 (Vadim Yanitskiy   2020-03-09 15:42:33 +0700 126)                     rxnb.dl->link_id = 0x80;
a955cfd4e (Harald Welte      2010-04-09 21:25:13 +0200 127)             else
f4fbafded (Harald Welte      2010-05-29 12:57:48 +0200 128)                     rxnb.dl->link_id = 0x00;

If MF_F_PTCCH is not set, then the rxnb.dl->link_id gets reset to 0x00. Booom! And look who did this:

commit 67c49ba664f7d7d7f07986a20e6d6363a27e3fc4
Author: Vadim Yanitskiy <axilirator@gmail.com>
Date:   Mon Mar 9 15:42:33 2020 +0700

    firmware/layer1: introduce experimental PDCH support

    This change implements basic (receive only) support of the PDCH
    channels that are used in GPRS. Several coding schemes are
    defined by 3GPP TS 45.003, however we can only do CS-1
    for now, since it's basically an equivalent of xCCH.

    In order to support the other schemes (CS2-4), we would need to
    know how to configure the DSP (look at Freecalypso code?).

    Change-Id: I44531bbe8743c188cc5d4a6ca2a63000e41d6189

SACCH is broken for nearly three years, and nobody even complained about that.

Actions
Copy link
 #4

Updated by Hoernchen about 1 year ago

But I complained about it! https://osmocom.org/issues/5133

Actions
Copy link
 #5

Updated by fixeria about 1 year ago

  • Related to Bug #5133: mishandling of the sacch l1 header added
Actions
Copy link
 #6

Updated by fixeria about 1 year ago

Hoernchen wrote in #note-4:

But I complained about it! https://osmocom.org/issues/5133

I thought this was in the context of using trxcon, not the layer1 firmware? Marking as related anyway.

Actions
Copy link
 #7

Updated by fixeria about 1 year ago

  • Status changed from In Progress to Feedback
  • % Done changed from 80 to 100

This patch fixes the problem:

https://gerrit.osmocom.org/c/osmocom-bb/+/30306 fixup: firmware/layer1: introduce experimental PDCH support [NEW]

Actions
Copy link
 #8

Updated by fixeria about 1 year ago

  • Status changed from Feedback to Resolved
Actions
Copy link

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)