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