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, That's wrong then. subscriber_id should be unique for AuthInfo, but not for > AuthTuples. We can (and should!) have multiple auth tuples for a > subscriber > and also think of a way how we can cycle through them (or randomly select > one > of them each time we need one) > AFAIK, the phone only keeps the data from last authentication ( Kc & key_seq ). When you send a CIPHER MODE COMMAND, it will use the last negotiated one, no choice there. The "key sequence" parameter which is given by the network during the authentication is just there so that on the next channel opening, the MS can send it (in LOC UPD REQ / PAGING RESP / CM SERV REQ) and the network can compare it to the last key_seq it emitted for this subscriber. * If they match, the network 'knows' that the last negotiated Kc is still ok (with a 1/16 chance of being wrong ...) and doesn't need a new authentication. * If they don't match, it's probably that the GSM has roamed somewhere else at some point and the Kc in the phone and in the Network don't match, so they need to renegotiate a new one. Keeping multiple AuthTuple for a subscriber would be useless since only the last one has usable data. And it's even easier if we only keep one because this way, to find the next "key sequence", we can just take the old stored one and increment it ... Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20100107/42d77bcc/attachment.htm>