GSM 04.08 L2 pseudo length in ACCH System Information messages

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Vadim Yanitskiy axilirator at gmail.com
Wed Dec 13 18:57:11 UTC 2017


Hi everyone,

I few days ago, during some usual R&D process, I noticed the following
messages, appearing in the log output of OsmocomBB/mobile application:

"ACCH message type 0xXX unknown."

The network, a phone was connected to, was may own and based on more
or less recent versions of OsmoNiTB, OsmoBTS, and OsmoTRX. Despite I
used to see such messages before, I didn't pay too much attention.
But this time I've decided to figure out, what's wrong there...

The source of such messages is the gsm48_rr.c / gsm48_rr_rx_acch():

static int gsm48_rr_rx_acch(struct osmocom_ms *ms, struct msgb *msg)
{
    // ...

    struct gsm48_system_information_type_header *sih = msgb_l3(msg);

    // ...

    switch (sih->system_information) {
    case GSM48_MT_RR_SYSINFO_5:
        return gsm48_rr_rx_sysinfo5(ms, msg);
    case GSM48_MT_RR_SYSINFO_5bis:
        return gsm48_rr_rx_sysinfo5bis(ms, msg);
    case GSM48_MT_RR_SYSINFO_5ter:
        return gsm48_rr_rx_sysinfo5ter(ms, msg);
    case GSM48_MT_RR_SYSINFO_6:
        return gsm48_rr_rx_sysinfo6(ms, msg);
    default:
        LOGP(DRR, LOGL_NOTICE, "ACCH message type 0x%02x unknown.\n",
            sih->system_information);
        return -EINVAL;
    }
}


To get I bit more details, I modified this function to print the
whole L3 payload, and got some interesting results. As it turned
out, the payloads were shifted one byte left - there was no
'l2_plen', which is assumed by:

/* Section 9.1.3x System information Type header */
struct gsm48_system_information_type_header {
    uint8_t l2_plen;
    uint8_t rr_protocol_discriminator :4,
        skip_indicator:4;
    uint8_t system_information;
} __attribute__ ((packed));


So, my first idea was that this is a bug of OsmocomBB, that
would be fairly easy to fix, so after a quick look at the
GSM 04.08 specification I wrote (and merged :/) this:

https://gerrit.osmocom.org/#/c/5204/

And everything was great, until I connected a 'patched' mobile to
a commercial mobile network... And all SI messages during a
dedicated connection were false-identified as SI5ter. This seemed
strange to me, so I decided to compare a SI message from commercial
network with a message captured in my own one:

https://habrastorage.org/webt/t8/zs/vv/t8zsvvjjglzfisnjqlnnsy4kgas.png

And this confused me even more, then I've expected. Why there is 0x49?
Wireshark false-identified this message as something related to SMS...
What if this is exactly the 'l2_plen' assumed in OsmocomBB before?

I looked at the specifications again, and found out that initially I
refered an outdated 5.3.0 version, which was the first link in Google:

http://www.etsi.org/deliver/etsi_gts/04/0408/05.03.00_60/gsmts_0408v050300p.pdf

while the latest one is 7.21.0:

http://www.etsi.org/deliver/etsi_ts/100900_100999/100940/07.21.00_60/ts_100940v072100p.pdf

So, I compared the 9.1.37-40 sections of both versions, and bingo!
In the higher version ACCH System Information messages do have the
'L2 Pseudo Length' (10.5.2.19) field.


Finally, what I've learned:

  - OsmocomBB / mobile follows the new version here (with l2_plen);
  - OsmoNiTB generates the ACCH SI messages without the l2_plen;
  - Recent Wireshark versions fail to decode the ACCH SI messages
    with l2_plen, while older ones are able to do that;
  - I should not merge the changes so quick.

My questions are:

  - Which way of composing the SI messages is correct?
  - If both are correct, how to parse them correctly?
  - Should we change OsmoNiTB / OsmoBSC to follow the latest specs?

And of course, I have to revert the change I've merged.

With best regards,
Vadim Yanitskiy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20171214/16660094/attachment.htm>


More information about the baseband-devel mailing list