Hi,
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