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/.
Robert Ingr ir at mytum.deHi, thanks for a quick reply. > > First: > > 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 > :) I'm sorry, i don't see why this is only an exceptional case, but ok. In our case it was always executed and hece the authentification was skipped. Or id rather say, the execution of comp128 was skipped due to an "invalid" key. The base station continued to work fine. We wouldn't have recognized it if we weren't waiting for the simcard to be asked to do the gsm_algorithm. I can just tell that for us, it always printed the LOG error in _use_comp128_v1 function from line 57 in openbsc/openbsc/src/libmsc/auth.c > > > > 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. > > > > > > > > > > Oh yay. Thanks for pointing this out. > > > > > > I had to implement it for pysim (since we support updating HLR db > directly from it) Ok, i used my own php script do manipulate the database directly. I figured it would be something with that dbi function. Thanks for the help! Regards, Robert