TLLI problems and proposed solution

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/.

Holger Hans Peter Freyther holger at freyther.de
Mon Jul 29 06:08:18 UTC 2013


On Mon, Jul 29, 2013 at 10:35:47AM +0800, Harald Welte wrote:
> Hi Holger,
> 
> just to explicitly respond to this sentence in your first message on the
>  subject:
> 
> On Sun, Jul 28, 2013 at 10:01:04PM +0200, Holger Hans Peter Freyther wrote:
> > So this means that for the entire GPRS attach procedure we will use the
> > initial foreign TLLI.... 
> 
> Which I believe is correct. The RAU_COMPLETE / ATTACH_COMPLETE should be
> the first message in downlink containing the new TLLI from my point of
> view.

Thank you for the detailed answer (in the other email). But doesn't this
mean that the gprs_llgmm_assign in gsm48_rx_gmm_att_req is a bit early?

E.g. something like this:

diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c
index f7a5cde..b981fb7 100644
--- a/openbsc/src/gprs/gprs_gmm.c
+++ b/openbsc/src/gprs/gprs_gmm.c
@@ -758,7 +758,7 @@ static int gsm48_rx_gmm_att_req(struct sgsn_mm_ctx *ctx, struct msgb *msg,
        ctx->tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL);
 
        /* 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,
                          GPRS_ALGO_GEA0, NULL);
 
        DEBUGPC(DMM, "\n");


and then in GMM_ATTACH_COMPLETE we will assign tlli_new?




More information about the OpenBSC mailing list