Bug #2951
openOsmoSGSN Accepts two MO L3 Messages with N(U) set to zero
50%
Description
- the MS sends its first GMM message "ATTACH REQUEST" in LLC with N(U) set to 0 (expected)
- the SGSN then inquires abou the IMEI using GMM "IDENTITY REQUEST"
- the MS subsequently sends its GMM "IDENTITY RESPONSE" in LLC with N(U) set to 0 again (broken behavior!)
Then OsmoSGSN still accepts that IDENTITY RESPONSE. This is odd. Later on, OsmoSGSN detects duplicate N(U) sequence numbers. But at the initial stage (or maybe when it's 0?) it doesn't detect the duplicate sequence number [which should be dropped].
Files
Updated by osmith almost 5 years ago
- File TC_attach_pdp_resp_nu_0.pcapng TC_attach_pdp_resp_nu_0.pcapng added
- % Done changed from 0 to 50
I've created a TTCN3 test case to reproduce and analyze this issue. The first two times, OsmoSGSN drops the message due to invalid N(U), hits a timeout and sends the identity request again:
20190619112529961 DLLC <0011> ../../../../src/osmo-sgsn/src/gprs/gprs_llc.c:858 TLLI=f0f864f2 dropping UI, N(U=0) not in window V(URV(UR:1). 20190619112535947 DMM <0002> ../../../src/libosmocore/src/fsm.c:284 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x562334545b70]{CheckIdentity}: Timeout of T3370 20190619112535947 DMM <0002> ../../../../src/osmo-sgsn/src/gprs/gprs_gmm.c:565 MM(262420000000002/f0f864f2) <- GPRS IDENTITY REQUEST: mi_type=IMEI
The third time, it performs recovery handling:
/* HACK: non-standard recovery handling. If remote LLE * is re-transmitting the same sequence number for * three times, don't discard the frame but pass it on * and 'learn' the new sequence number */
So this seems to be a feature, not a bug?
WIP test case: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/14516
laforge: how to proceed here, should we instantly reject N(U) = 0 during identity response messages, because it never makes sense?
Do we have more information about how this issue was discovered?