diff options
| author | Pau Espin Pedrol <pespin@sysmocom.de> | 2023-07-31 18:12:55 +0200 |
|---|---|---|
| committer | Pau Espin Pedrol <pespin@sysmocom.de> | 2023-07-31 18:12:57 +0200 |
| commit | 171ba463828af143911d38e8a4885759f9d2e389 (patch) | |
| tree | dce9567a2690561d995942b8c4895372c8f0d7cd | |
| parent | e2fd48e7d783a92e862527d5d5b88e6c14dc06d2 (diff) | |
layer23: modem: gmm: Adapt log string about no TLLI found
During initial GMM Attach, the GMM layer generates an internal
local TLLI and uses it to do the GMM Attach. Only at the time it
receives the GMM Attach Accept with the assigned TLLI from the network
then explicitly informs other layers about the TLLI update.
Hence, the GMMREG user doesn't really know about the TLLI in use until
the GMM Attach success happens (gmmreg-attach.cnf).
During that time, the TLLI at the app is basically unassigned
(0xffffffff). Hence, during that same time a TLLI update hook in
GMMRR-Assign.req will not work since the app is unaware of the remporary
local TLLI, so no match can be done.
In that specific scenario, that's fine, since anyway it is waiting to
receive the GMMREG-Attach.cnf, which will indicate the assigned TLLI to
it.
In summary, not being able to match the TLLI in GMMRR-Assign.req is not
bad per se, so soften the log error there.
Change-Id: I31c04288789393391084000fbdbcdcedb11d0b68
| -rw-r--r-- | src/host/layer23/src/modem/gmm.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/host/layer23/src/modem/gmm.c b/src/host/layer23/src/modem/gmm.c index b8df38b4..c0e69368 100644 --- a/src/host/layer23/src/modem/gmm.c +++ b/src/host/layer23/src/modem/gmm.c @@ -162,7 +162,7 @@ static int modem_gmm_prim_down_cb(struct osmo_gprs_gmm_prim *gmm_prim, void *use } } else { if (old_tlli != OSMO_GPRS_GMM_TLLI_UNASSIGNED) - LOGP(DGMM, LOGL_ERROR, "%s(): Unexpected Rx %s with unknown TLLI=0x%08x\n", + LOGP(DGMM, LOGL_NOTICE, "%s(): Rx %s with unknown TLLI=0x%08x, probably the MS is still attaching\n", __func__, pdu_name, old_tlli); } |