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/.
Sylvain Munaut 246tnt at gmail.comHi, > First: > In file openbsc/openbsc/src/libmsc/db.c on line 372 there is > > "ainfo->a3a8_ki_len = sizeof(ainfo->a3a8_ki_len);" > > which takes the sizeof of the length value. This always results in a wrong keylength and hence no authentification will ever be executed. This should rather be changed to: > > ainfo->a3a8_ki_len = sizeof(ainfo->a3a8_ki); There is indeed a bug. But it's only in the "exception" processing, so in a normal case that shouldn't have prevented auth. (and since we use auth at the camp and 27c3, I can guarantee it works in the normal case :) > Secondly: > I haven't found the piece of code which is responsible for this bug particulary but: > Whenever the key for the a3a8_comp128 is being read from the database a shift of one bit occurs. > > i.e. when you set the a3a8_key in the hlr.sqlite3 to 01010101010101010101010101010101 the value being processed as key in the a3a8_comp128 algorithm is 02020202020202020202020202020202. That's not a bug per-se. I think you're assuming the binary value stored in the field is used as key. This is _not_ the case. libdbi has some special binary escaping that results in the binary value stored not being the "raw" key. You have to either: - Use the vty to set the key - Set the key using libdbi - Escape the binary value yourself the same way as libdbi does. Cheers, Sylvain