29 Jul
2013
29 Jul
'13
1:21 p.m.
On Mon, Jul 29, 2013 at 06:04:05PM +0800, Harald Welte wrote:
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.
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? 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.