tree 5e02d316a174867475b952626e1360099c957b6d
parent 7a92d5fbc008ba7c3085fe1b524424a32da3a49f
author Vadim Yanitskiy <vyanitskiy@sysmocom.de> 1675805031 +0700
committer Vadim Yanitskiy <vyanitskiy@sysmocom.de> 1675806862 +0700

library/GSM_Types: fix encoding of BcdMccMnc (3 octets)

In [1] I copied the hexstring concatenation statement for the 3-digit
MNC from the original function f_enc_BcdMccMnc(), which was renamed
to f_enc_BcdMccMnc_int().  Unfortunately, this statement (originally
introduced in commit [2]) is incorrect.

In our implementation a pair of MCC and MNC is encoded as follows:

  | MCC digit 1 | MCC digit 2 |  octet 1
  | MNC digit 3 | MCC digit 3 |  octet 2
  | MNC digit 1 | MNC digit 2 |  octet 3

Additionally, in the case of a 2-digit MNC, the original variant
of f_enc_BcdMccMnc() (before [1]) would swap MCC and MCC in the
2nd octet, generating even more unpredictable results.

According to 3GPP TS 24.008, Figure 10.5.13, the correct coding is:

  | MCC digit 2 | MCC digit 1 |  octet 1
  | MNC digit 3 | MCC digit 3 |  octet 2
  | MNC digit 2 | MNC digit 1 |  octet 3

So far the only user of this API is the PCU_Tests module.  Looking
at the PCAPs of testcases invoking this function, Wireshark indeed
shows weird MCC/MNC values (expected 262/42):

  Routing area identification: 23-43-423-2
    Mobile Country Code (MCC): Unknown (23)
    Mobile Network Code (MNC): Unknown (43)
    Location Area Code (LAC): 0x01a7 (423)
    Routing Area Code (RAC): 0x02 (2)

Change-Id: Ifa3083fdd6307b56baa1ef3ac85a3e7a2efab728
Related: [1] 7a92d5fbc008ba7c3085fe1b524424a32da3a49f
Fixes: [2] 0637ba072820a370ed539ab0e23f8ded8bce6d16