<div dir="ltr">Hi everyone,<br><br>I few days ago, during some usual R&D process, I noticed the following<br>messages, appearing in the log output of OsmocomBB/mobile application:<br><br>"ACCH message type 0xXX unknown."<br><br>The network, a phone was connected to, was may own and based on more<br>or less recent versions of OsmoNiTB, OsmoBTS, and OsmoTRX. Despite I<br>used to see such messages before, I didn't pay too much attention.<br>But this time I've decided to figure out, what's wrong there...<br><br>The source of such messages is the gsm48_rr.c / gsm48_rr_rx_acch():<br><br>static int gsm48_rr_rx_acch(struct osmocom_ms *ms, struct msgb *msg)<br>{<br>    // ...<br><br>    struct gsm48_system_information_type_header *sih = msgb_l3(msg);<br><br>    // ...<br><br>    switch (sih->system_information) {<br>    case GSM48_MT_RR_SYSINFO_5:<br>        return gsm48_rr_rx_sysinfo5(ms, msg);<br>    case GSM48_MT_RR_SYSINFO_5bis:<br>        return gsm48_rr_rx_sysinfo5bis(ms, msg);<br>    case GSM48_MT_RR_SYSINFO_5ter:<br>        return gsm48_rr_rx_sysinfo5ter(ms, msg);<br>    case GSM48_MT_RR_SYSINFO_6:<br>        return gsm48_rr_rx_sysinfo6(ms, msg);<br>    default:<br>        LOGP(DRR, LOGL_NOTICE, "ACCH message type 0x%02x unknown.\n",<br>            sih->system_information);<br>        return -EINVAL;<br>    }<br>}<br><br><br>To get I bit more details, I modified this function to print the<br>whole L3 payload, and got some interesting results. As it turned<br>out, the payloads were shifted one byte left - there was no<br>'l2_plen', which is assumed by:<br><br>/* Section 9.1.3x System information Type header */<br>struct gsm48_system_information_type_header {<br>    uint8_t l2_plen;<br>    uint8_t rr_protocol_discriminator :4,<br>        skip_indicator:4; <br>    uint8_t system_information;<br>} __attribute__ ((packed));<br><br><br>So, my first idea was that this is a bug of OsmocomBB, that<br>would be fairly easy to fix, so after a quick look at the<br>GSM 04.08 specification I wrote (and merged :/) this:<br><br><a href="https://gerrit.osmocom.org/#/c/5204/">https://gerrit.osmocom.org/#/c/5204/</a><br><br>And everything was great, until I connected a 'patched' mobile to<br>a commercial mobile network... And all SI messages during a<br>dedicated connection were false-identified as SI5ter. This seemed<br>strange to me, so I decided to compare a SI message from commercial<br>network with a message captured in my own one:<br><br><a href="https://habrastorage.org/webt/t8/zs/vv/t8zsvvjjglzfisnjqlnnsy4kgas.png">https://habrastorage.org/webt/t8/zs/vv/t8zsvvjjglzfisnjqlnnsy4kgas.png</a><br><br>And this confused me even more, then I've expected. Why there is 0x49?<br>Wireshark false-identified this message as something related to SMS...<br>What if this is exactly the 'l2_plen' assumed in OsmocomBB before?<br><br>I looked at the specifications again, and found out that initially I<br>refered an outdated 5.3.0 version, which was the first link in Google:<br><br><a href="http://www.etsi.org/deliver/etsi_gts/04/0408/05.03.00_60/gsmts_0408v050300p.pdf">http://www.etsi.org/deliver/etsi_gts/04/0408/05.03.00_60/gsmts_0408v050300p.pdf</a><br><br>while the latest one is 7.21.0:<br><br><a href="http://www.etsi.org/deliver/etsi_ts/100900_100999/100940/07.21.00_60/ts_100940v072100p.pdf">http://www.etsi.org/deliver/etsi_ts/100900_100999/100940/07.21.00_60/ts_100940v072100p.pdf</a><br><br>So, I compared the 9.1.37-40 sections of both versions, and bingo!<br>In the higher version ACCH System Information messages do have the<br>'L2 Pseudo Length' (10.5.2.19) field.<br><br><br>Finally, what I've learned:<br><br>  - OsmocomBB / mobile follows the new version here (with l2_plen);<br>  - OsmoNiTB generates the ACCH SI messages without the l2_plen;<br>  - Recent Wireshark versions fail to decode the ACCH SI messages<br>    with l2_plen, while older ones are able to do that;<br>  - I should not merge the changes so quick.<br><br>My questions are:<br><br>  - Which way of composing the SI messages is correct?<br>  - If both are correct, how to parse them correctly?<br>  - Should we change OsmoNiTB / OsmoBSC to follow the latest specs?<br><br>And of course, I have to revert the change I've merged.<br><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>With best regards,<br></div><div>Vadim Yanitskiy.<br></div></div></div></div></div></div>
</div>