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/.
Harald Welte laforge at gnumonks.orgHi Holger, On Mon, Jul 29, 2013 at 08:08:18AM +0200, Holger Hans Peter Freyther wrote: > > 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: > > /* 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? This would be the following case: 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. However, what we want at this point is to accept old _and_ new TLLI, which is: 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 Old and TLLI New are assigned, and TLLI New shall be used when (re-)transmitting LLC frames. Both TLLI Old and TLLI New shall be accepted when received from the peer. It shall be treated as a TLLI change according to subclause 8.3.2. So we accept both old and new from the MS, which is what we want. However, to my understanding, we actually don't want to use the new TLLI for TX, which is why we use msgb_tlli(msg) = old_tlli to explicitly request that tlli to be used. So I still think that at least _this_ part of the existing code is doing it right. Regards, Harald -- - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)