GSM 04.08 L2 pseudo length in ACCH System Information messages
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.
Hi Vadim,
On Thu, Dec 14, 2017 at 01:57:11AM +0700, Vadim Yanitskiy wrote:
> 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.
I think you have to review the matching 04.06 / 44.006 together with it.
My suspicion is that earlier, 04.06 might not have specified the B4 frame
format for downlink SACCH but simply used a normal B frame format (with length
octet at L2). Or specified that the B4 frame format includes the length octet.
It looks like what used to be a regular UI frame length octet in L2 has at some
point been moved into L3 in order to achieve phase1 compatibility by having
a length octet that's shorter than the payload length. Old phones will then only
look at the "length" number of bytes, where newer phones will look at the full message.
If they kept the length octet in L2, L2 would have automatically calculated the length
to the total length of the message, including all phase2 extensions. So I guess
that's why they came up with that ugly hack of defining L2 as not having a length
(only addr + ctrl on downlink sacch) and the L3 including a length octet.
>From the wire format point of view, you always have
* two octets L1 header (power control, TA loop)
* one octet ADDR
* one octet CTRL
* one octet [either L2 length or L2 pseudo length]
* the actual L3 payloda
The question is just whether you group ADDR+CTRL+LEN into L2 or you put LEN+L3 into L3.
If my line of thinking is correct (see https://osmocom.org/issues/3059)
we need to make sure
* the L2 pseudo-length is included in all SACCH downlink L3 info on RSL,
see https://gerrit.osmocom.org/#/c/7220/
* fix the wireshark dissector for SACCH, see https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14105
* fix the wireshark RSL dissector for RSL (SACCH FILL, SACCH INFO MODIFY, CHAN ACT)
Regards,
Harald
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
participants (2)
-
Harald Welte -
Vadim Yanitskiy