Hi Sylvain,
On Wed, Jun 09, 2010 at 09:43:07AM +0200, Sylvain Munaut wrote:
One thing I didn't yet figure out is the HLR part on how to have a neat interface to store retrieve keys / authentication methods available and previous tuples. What's currently implemented is not good, I misuse the AuthTuple thing to store current authentication and not possible tuples to use when we don't know Ki.
I have to check your code. My idea was to have two tables, one for actual keys (ki), and the other one for auth tuples. The tuples would probably need a 'last used' counter, so we can make sure we don't use the most recently used tuples again.
Once we move to a 'more real' HLR, there will be an asynchronous request from MSC to HLR to obtain authentication tuples. Those tuples are then stored in the MSC-internal (volatile) VLR.
well, it is not ready (as it is untested right now and I had to do lots of manual fixes during rebase) ... and it introduces lots of layer3 code (encryption command, etc) in the regular gsm_04_08.c file...
Should those go elsewhere ? How should it be split ?
We right now have gsm_04_08.c and gsm_04_08_utils.c... The _utils.c is used from both 'real BSC' and bsc_hack, and the plain 04_08.c is used only by the bsc_hack.
So you actually have it in the right file, I was wrong. Thus, we could merge it. However, this part will nonetheless probably change a lot once we make the split...
I put gsm48_secure_channel (and supporting code) in gsm_04_08.c mainly because it needs to be called when there is a location update request (among other cases) and the loc update handling code is entirely in gsm_04_08.c
sure.
I guess I must read on on what exactly is MSC domain and what is BSC domain, so far I mostly focused on 04.08 without paying attention to who is supposed to handle what ...
I think in general it's quite simple. The BSC handles RR (like channel request, immediate assign, paging), whereas MM, CC, SMS, etc. are handled by the MSC.
Regards, Harald