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
