Project

General

Profile

Actions

Feature #3189

closed

make retrieval of IMEI configurable

Added by neels almost 6 years ago. Updated about 5 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
04/19/2018
Due date:
% Done:

100%

Resolution:
Spec Reference:

Description

We already have flags that trigger retrieving of IMEI / IMEISV in the course of the VLR's FSMs.
We also have unit tests that go through these scenarios and verify they work.
What we still need is to switch them on: add vty config to set vlr_instance.cfg values:
  • check_imei_rqd
  • retrieve_imeisv_early
  • retrieve_imeisv_ciphered

Related issues

Related to OsmoHLR - Feature #2541: have IMEI in HLR DBResolvedosmith10/06/2017

Actions
Related to Cellular Network Infrastructure - Feature #3733: Send IMEI from MSC to HLRResolvedosmith12/14/2018

Actions
Related to OsmoMSC - Feature #3755: make retrieval of IMEISV configurableNew01/10/2019

Actions
Actions #1

Updated by neels almost 6 years ago

Actions #2

Updated by laforge almost 6 years ago

  • Priority changed from Normal to Low
Actions #3

Updated by osmith over 5 years ago

  • Status changed from New to In Progress
  • Assignee set to osmith
  • % Done changed from 0 to 90

#2541 depends on this, so I wrote a patch to implement it. I didn't know how to describe all of the parameters though.

https://gerrit.osmocom.org/#/c/osmo-msc/+/12302/

I've tried to test it, but was unsuccessful:
  • set "check-imei-rqd 1" in osmo-msc.cfg
  • run the CN with a sysmoBTS connected
  • run wireshark with filter set to: gsup
  • connect a phone
  • now I expected some check-imei-related messages to appear. But I only got the usual:

UpdateLocation Request
InsertSubscriberData Request
InsertSubscriberData Result
UpdateLocation Result

neels, laforge: what does this mean, was my testing done wrong?

Actions #4

Updated by osmith over 5 years ago

Actions #5

Updated by osmith over 5 years ago

Turns out, we don't send a GSUP message to the HLR/EIR yet (this explains my wireshark test results).

This issue should be complete with the submitted patch nevertheless, but we still need to fill in the missing descriptions.

Actions #6

Updated by osmith about 5 years ago

I've changed the patch to only enable check-imei-rqd, because that is the only option that is useful so far. It will send the IMEI to the HLR/EIR, as it has just been implemented in #3733.

The other options are not that useful yet, they will ask the device for the IMEISV, but then do nothing with it.
See neels' third reply here: https://gerrit.osmocom.org/#/c/osmo-msc/+/12302/1/src/libmsc/msc_vty.c@448

The patch has been merged.

neels: can we set this issue to resolved?

Actions #7

Updated by neels about 5 years ago

even though IMEISV is only stored in VLR, that part is not configurable yet, right?
We could split this issue: make this one ask for IMEI only and create a new one for IMEISV.
We could also just add vty config for IMEISV even if nothing is happening with it, and add IMEISV->HLR some other time.

Actions #8

Updated by osmith about 5 years ago

  • Related to Feature #3755: make retrieval of IMEISV configurable added
Actions #9

Updated by osmith about 5 years ago

  • Subject changed from make retrieval of IMEI, IMEISV configurable to make retrieval of IMEI configurable
  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

even though IMEISV is only stored in VLR, that part is not configurable yet, right?

Right.

We could split this issue: make this one ask for IMEI only and create a new one for IMEISV.

Sounds good, done: #3755.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)