Project

General

Profile

Actions

Bug #2951

open

OsmoSGSN Accepts two MO L3 Messages with N(U) set to zero

Added by laforge about 6 years ago. Updated over 4 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
02/16/2018
Due date:
% Done:

50%

Spec Reference:

Description

when
  • 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

Actions #1

Updated by laforge almost 6 years ago

  • Assignee changed from 4368 to lynxis
Actions #2

Updated by laforge over 5 years ago

  • Assignee changed from lynxis to osmith
Actions #3

Updated by osmith almost 5 years ago

  • Status changed from New to In Progress
Actions #4

Updated by osmith over 4 years ago

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?

Actions #5

Updated by osmith over 4 years ago

  • Status changed from In Progress to Feedback
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)