Hello everybody, after setting up a nanoBTS with OpenBSC/SGSN/GGSN, I had some troubles trying to connect my smartphone to the GPRS cell. Investigating the BTS-to-SGSN traffic, I saw that the frames sent by the SGSN were all marked with the same N(U) value (at LLC layer), the value was 0. With some debug, I found that the there was a mismatch in the TLLI storage, used to keep the status of attached terminals. The mentioned code is contained in gprs_llc.c, involving LL Entity functions and gprs_llc_tx_ui(). /* look-up or create the LL Entity for this (TLLI, SAPI) tuple */ lle = lle_by_tlli_sapi(msgb_tlli(msg), sapi); if (!lle) { struct gprs_llc_llme *llme; LOGP(DLLC, LOGL_ERROR, "LLC TX: unknown TLLI 0x%08x, " "creating LLME on the fly\n", msgb_tlli(msg)); llme = llme_alloc(msgb_tlli(msg)); lle = &llme->lle[sapi]; } The TX function uses the previously received TLLI to lookup for the LLE. The lle_by_tlli_sapi() performs the search, but preliminary it applies a foreign2local TLLI conversion to ensure to have a local one. Since no valid entry for the searched TLLI is found, a new one is created. And the problem is here. The new entry has the foreign TLLI. Next time the lookup fails again, and a new entry is created. This way, the counter N(U) is always reset, and the mobile do not recognize the message sequence and no attach is possible. My question is about foreign and local TLLIs. I patched the lookup, avoiding the conversion, so that the LLE is found and everything works fine... but... What is the sense of the conversion? Should the TLLI be always stored as a local one? Can this problem be solved with another foreign2local while allocating new entries? Actually, my problem has been solved with that workaround. But I'm curious to know what is the right way. Hope somebody can answer :) Thanks. Cheers, LM
Hi Luca, On Fri, Jan 21, 2011 at 06:44:03AM +0100, Luca Melette wrote:
after setting up a nanoBTS with OpenBSC/SGSN/GGSN, I had some troubles trying to connect my smartphone to the GPRS cell.
Investigating the BTS-to-SGSN traffic, I saw that the frames sent by the SGSN were all marked with the same N(U) value (at LLC layer), the value was 0.
With some debug, I found that the there was a mismatch in the TLLI storage, used to keep the status of attached terminals.
This is probably related to some recent changes like f6bd340df6bcac716da78da8e35f379a7b853027 where I tried to fix the TLLI lookup in case a MS moves from one RA to another. It seems instead of fixing it, I have made things worse. Try to revert that patch...
My question is about foreign and local TLLIs. I patched the lookup, avoiding the conversion, so that the LLE is found and everything works fine... but...
What is the sense of the conversion?
Should the TLLI be always stored as a local one?
Can this problem be solved with another foreign2local while allocating new entries?
It is a hard problem that has caused already quite a lot of headaches to me. 1) we should never create a new TLLI in our map on outgoing transfers 2) we need to get all the TLLI transitions/translations right (from GMM -> LLC layer. Special care has to be taken in the case that two different TLLI values are acceptable for the same MS, e.g. in case of TMSI reallocation or some message losses (remember: as opposed to MM, GMM messages can be dropped by the lower layers).
Actually, my problem has been solved with that workaround. But I'm curious to know what is the right way.
I am very happy to get your input on the problem. As indicated, I've already spent a number of hours trying to come up with a solution that's correct in all cases, but have failed to do so. Prior to my December 23rd changes, it was working fine with a single BTS in a single RA. But once you start to see MS moving betwen RA, the old code did not correctly resolve the foreign TLLI in the new RA to the old 'local' TLLI. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi, * Harald Welte <laforge@gnumonks.org> [2011-01-25 14:59]:
On Fri, Jan 21, 2011 at 06:44:03AM +0100, Luca Melette wrote:
after setting up a nanoBTS with OpenBSC/SGSN/GGSN, I had some troubles trying to connect my smartphone to the GPRS cell.
Investigating the BTS-to-SGSN traffic, I saw that the frames sent by the SGSN were all marked with the same N(U) value (at LLC layer), the value was 0.
With some debug, I found that the there was a mismatch in the TLLI storage, used to keep the status of attached terminals.
This is probably related to some recent changes like f6bd340df6bcac716da78da8e35f379a7b853027 where I tried to fix the TLLI lookup in case a MS moves from one RA to another. It seems instead of fixing it, I have made things worse. Try to revert that patch...
I'm not completely sure if my problem is from the same origin (I just started to look into using openbsc with gprs). However this patch did not resolve my problem. What I see in osmo-sgsn is: <0016> gprs_bssgp.c:346 BSSGP TLLI=0xa2d141c3 UPLINK-UNITDATA <0017> gprs_llc.c:428 LLC SAPI=1 C FCS=0x797ccfCMD=UI DATA <0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3 <0017> gprs_llc.c:700 LLC RX: unknown TLLI 0x08x, creating LLME on the fly <0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3 <0017> gprs_llc.c:342 LLC TX: unknown TLLI 0xa2d141c3, creating LLME on the fly <0016> gprs_bssgp.c:346 BSSGP TLLI=0xa2d141c3 UPLINK-UNITDATA <0017> gprs_llc.c:428 LLC SAPI=1 C FCS=0xcd35c4CMD=UI DATA <0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3 <0017> gprs_llc.c:700 LLC RX: unknown TLLI 0x08x, creating LLME on the fly <0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3 <0017> gprs_llc.c:342 LLC TX: unknown TLLI 0xa2d141c3, creating LLME on the fly <0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3 <0017> gprs_llc.c:342 LLC TX: unknown TLLI 0xa2d141c3, creating LLME on the fly <0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3 <0017> gprs_llc.c:342 LLC TX: unknown TLLI 0xa2d141c3, creating LLME on the fly <0016> gprs_bssgp.c:346 BSSGP TLLI=0xa2d141c3 UPLINK-UNITDATA <0017> gprs_llc.c:428 LLC SAPI=1 C FCS=0x804229CMD=UI DATA <0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3 <0017> gprs_llc.c:700 LLC RX: unknown TLLI 0x08x, creating LLME on the fly <0002> gprs_gmm.c:213 Starting MM timer 3370 while old timer 3370 pending <0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3 <0017> gprs_llc.c:342 LLC TX: unknown TLLI 0xa2d141c3, creating LLME on the fly <0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3 <0017> gprs_llc.c:342 LLC TX: unknown TLLI 0xa2d141c3, creating LLME on the fly <0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3 <0017> gprs_llc.c:342 LLC TX: unknown TLLI 0xa2d141c3, creating LLME on the fly <0016> gprs_bssgp.c:346 BSSGP TLLI=0xa2d141c3 UPLINK-UNITDATA <0017> gprs_llc.c:428 LLC SAPI=1 C FCS=0xfcdd5aCMD=UI DATA <0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3 <0017> gprs_llc.c:700 LLC RX: unknown TLLI 0x08x, creating LLME on the fly <0002> gprs_gmm.c:213 Starting MM timer 3370 while old timer 3370 pending openbsc before: <0005> abis_nm.c:537 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) Which will repeat over and over again as long as the MS tries to connect. There is only one RA in this scenario. As mentioned I just started looking into gprs so any pointer on how to debug this further or add missing information are welcome. Apologies for hijacking this thread if this is a different problem. Cheers Nico
On Tue, 1 Feb 2011 21:15:13 +0100 Nico Golde <openbsc@ngolde.de> wrote: Hi Nico,
I'm not completely sure if my problem is from the same origin (I just started to look into using openbsc with gprs). However this patch did not resolve my problem.
This is what I've done. diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index 7991f4c..969c224 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -126,7 +126,7 @@ static struct gprs_llc_lle *lle_by_tlli_sapi(uint32_t tlli, uint8_t sapi) { struct gprs_llc_llme *llme; - tlli = tlli_foreign2local(tlli); + //tlli = tlli_foreign2local(tlli); llist_for_each_entry(llme, &gprs_llc_llmes, list) { if (llme->tlli == tlli || llme->old_tlli == tlli) Let me know if it works for you. Cheers, LM
Hi, * Luca Melette <luca@srlabs.de> [2011-02-03 11:34]:
On Tue, 1 Feb 2011 21:15:13 +0100 Nico Golde <openbsc@ngolde.de> wrote:
I'm not completely sure if my problem is from the same origin (I just started to look into using openbsc with gprs). However this patch did not resolve my problem.
This is what I've done. [...] Let me know if it works for you.
Indeed, this improved things. Thanks a lot! Cheers Nico
The best thing about Melon Sandbox is how free it is. You start with a https://snow-rider3d.io simple world and a toolbox full of "melons," which are items, weapons, vehicles, and characters.
Great breakdown of the foreign vs local TLLI issue — this kind of edge case is easy to miss but critical for stability. I recently covered a similar deep-dive on protocol handling here: https://quibohub.com/parallel-concurrent-processing/
participants (5)
-
geohearttry＠gmail.com -
Harald Welte -
Luca Melette -
Nico Golde -
williamz.debra＠gmail.com