Project

General

Profile

Bug #3652

Incorrect IMEISV setting in mobile application

Added by falconia about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
OsmocomBB mobile (host)
Target version:
-
Start date:
10/12/2018
Due date:
% Done:

0%

Resolution:
Spec Reference:
GSM 02.16, 3GPP 22.016, GSMA TS.06

Description

Per GSM, 3GPP and GSMA specs an IMEI consists of 14 content digits plus one check digit, whereas an IMEISV consists of 14 digits of IMEI plus 2 digits of Software Version. The SV field is distinct from the Luhn check digit, and while in some existing commercial implementations (Openmoko GTA01/02 and Pirelli DP-L10 are known examples) the combination of firmware design and factory flash record programming results in a "software version" field being transmitted to the network that really consists of the Luhn check digit and a zero, this quirk of legacy implementations should be considered a defect and should not be replicated in new product and software designs. In particular, GSMA TS.06 (V14.0 current as of this writing) states in section C.4 that "All ME designed to Phase 2 or later requirements shall increment the SVN for new versions of software. The initial version number shall be 00", which is clearly incompatible with using the Luhn check digit from the IMEI part as the first digit of the transmitted SVN.

In the case of OsmocomBB, the "imei" setting in the mobile application does not allow the user to set their IMEI and SV according to the standards. This setting currently takes a 15-digit IMEI argument and a single-digit (as opposed to 2-digit) SV argument, misleading the user into thinking that the air interface standards allow only one digit for the software version and practically resulting in the first digit of the transmitted SV being set to the Luhn check digit, as the 15-digit IMEI argument required by the setting will normally be entered by any naive user with that check digit at the end.

Some GSM MS hardware manufacturers such as myself reluctantly allow the use of OsmocomBB software with our physical GSM transceiver hardware, however, if someone runs OsmocomBB on our hw and uses the resulting combination to connect to public GSM networks with the transmitter enabled (contrary to the LegalAspects page in the OsmocomBB wiki which clearly states that such usage is not recommended and likely to be illegal), we, the manufacturers of hardware that is NOT specifically designed for OsmocomBB but allows its use, ask that OsmocomBB users clearly identify themselves to the networks they are connecting to by transmitting a different SV number (if they use our factory-assigned IMEI) than the SV number transmitted by our official firmware. The objective is to make it easy for network operators to clearly distinguish between users of OsmocomBB software vs. users of the manufacturer's official type-approved firmware, so that in the case of any radio misbehaviour the blame will be directed to the correct party. In order to comply with this reasonable request from type-approved device manufacturers who do not wish to be unfairly blamed for network disruptions caused by non-type-approved OsmocomBB software, OsmocomBB users need to be able to unambiguously set the full SV field of their IMEISV, which the current state of the software does not allow to be done in an intuitive manner.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)