17 Jun
2010
17 Jun
'10
10:47 p.m.
I landed the first big change, the gsm48_rcvmsg is now
inside the
bsc_api.c. And on first msg the BSC API will call the compl_l3 (COMPLETE
LAYER3) callback. This method will always be called for any new
connection and is the perfect place to enable encryption..
Looking into it, however I'm not yet sure how it will turn out because
of the quirks of encryption I mentionned on IRC.
Namely:
- ciph mode command is implicit cm serv accept
- need to extract key_seq from the various possible message
- not all incoming message can trigger the auth procedure. (IMSI
DETACH for example doesn't support it AFAICT)
So it'll have to somehow be a three step process:
- Pre-treatment of the first message (possibly the end of the
treatment if nothing else supported or if it's a reject of some kind)
- Run the auth/ciphering procedure (and possibly other could be
plugged in, like the class mark or identity request procedure)
but then again, there are interaction between those, they're not
fully isolated.
- Proceed with the rest of the first message (but need some feed back
from the other procedure that have been run ...)
I'm wondering : Can those 'initial l3 messages' sometime appear 'in
the middle' of an already established channel ?
Another task would be to move the Cipher Mode code
into the BSC API, the
gsm_04_08.c code should not directly change the attributes in the lchan
and should not send the cipher mode RR message.
Ok, I'm on it.
My current approach will be to just implement cipher related BSSMAP
messages of GSM 08.08 as function calls back & forth the msc / bsc
domain. This way for a real worlds msc connection, it would just need
to implement the wrapping / unwrapping of those in a real SCCP/BSSMAP
connection.
(that's the idea if I understood the code correctly)
Sylvain