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....

while the latest one is 7.21.0:

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

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.