On Mon, Jul 29, 2013 at 06:04:05PM +0800, Harald Welte wrote:
Hi Holger,
Good Evening,
/* Inform LLC layer about new TLLI but keep old active */
gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new,
gprs_llgmm_assign(ctx->llme, 0xffffffff,, ctx->tlli,Why?
Well, in case of GPRS Attach of a roaming subscriber: ctx->tlli_new is the local TLLI based on the P-TMSI we didn't assign ctx->tlli is the foreign TLLI based on this P-TMSI.
In that case tlli_new will never be used in the traffic, e.g. we would assig a new P-TMSI based on the GPRS Attach. Given how much/little I understand right now.. the tlli_new will not be used by us or the phone during the attachment procedure.
LLGMM-ASSIGN.req (7.2.1.1 of 04.64): The TLLI Old and TLLI New parameters shall be interpreted as follows: If TLLI Old = all 1's and TLLI New ≠ all 1's then TLLI New shall be assigned and used when (re-)transmitting LLC frames. If a TLLI Old ≠ all 1's was assigned to the LLME, then TLLI Old is unassigned. Only TLLI New shall be accepted when received from the peer. It shall be treated as a TLLI change according to subclause 8.3.2.
This would mean that the tlli_old (which is stored in the LLME up to the call to your proposed "gprs_llgmm_assign(ctx->llme, 0xffffffff, ctx->tlli") would no longer be accepted on the Rx side.
So I assume that:
llme->old_tlli = 0xff...; llme->tlli = a foreign TLLI;
gprs_llgmm_assign(llme, 0xff.., llme->tlli);
this would be the "TLLI Assignment 8.3.1" case? It would also reset all the lle's.
So I still think that at least _this_ part of the existing code is doing it right.
Okay, it is certainly not a bug and might even be correct. So there is no point in changing this code.