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/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deHi list, today I saw an MM Authentication Response sent from a 3G UE that mismatches the GSM 04.08 spec. The spec says 0x14, the 3G phone sent 0x94. And wireshark agrees that 0x94 is an Authentication Response. The spec ETSI TS 100 940 V7.21.0 (2003-12) chapter 10.4 defines the MM Authentication Response message type as 8 7 6 5 4 3 2 1 0 x 0 1 - - - - Security messages: 0 1 0 0 AUTHENTICATION RESPONSE So this would be 0x14 or 0x54, depending on the don't-care bit 7. The Osmocom code acts according to spec by applying a bitmask of 0xbf (0b10111111) before comparing to 0x14, caring about bit 8. However, the 3G phone sent an Authentication Response message type of 0x94 (0b10010100) with bit 8 set. Interestingly enough, wireshark interprets this as a 0x14 with the highest two bits as sequence nr. So it seems the reality in the field differs from the spec in that bit 8 should be masked away before comparing to the MM message type code. In consequence, I need to adjust the MM message type bitmask to 0x3f in upcoming patches. The thing is, our code has the apparently wrong 0xbf bitmask hardcoded in numerous places. So as a first step, I will introduce bitmask #defines in libosmocore and apply these in openbsc. I will introduce separate bitmask defines for MM and CC messages, because I'm not sure yet whether CC message types should also be masked with 0x3f in the field and will leave the CC mask as 0xbf for now. While doing that, I also noticed that some places apply a 0xbf bitmask even though the message types in question aren't defined as having any don't-care bit in TS 100 940. I'll adjust those in a separate patch. - So at first, I will replace 0xbf with GSM48_MT_MM_MSG_TYPE_MASK or GSM48_MT_CC_MSG_TYPE_MASK. - Then I'll adjust the MM mask to 0x3f to allow testing 3G auth. - Finally I'll remove bit masks where they shouldn't be applicable, which could use a second opinion by you guys. Are the upper bits always some sequence number, and the spec simply doesn't reflect the field? The patch submissions will follow right up... ~Neels -- - Neels Hofmeyr <nhofmeyr at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160310/89ce04be/attachment.bin>