TLLI problems and proposed solution

[Holger Hans Peter Freyther]

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.