usage of plmn_buf_to_str and plmn_str_to_buf to process PLMNIdentity fields

[ravens]

Hi!

I have been noticing that some functions, like globenbid_to_hum() are using plmn_str_to_buf and plmn_buf_to_str to parse/encode PLMNIdentity fields in NGAP/S1AP, according to the following line for example: https://github.com/P1sec/pycrate/blob/839291c8e83719bbd607542273d41eb920a2911b/pycrate_corenet/utils_fmt.py#L84

However, this does not work for some PLMN like T-mobile US (310160):

utils_fmt.plmn_buf_to_str(b'\x13\x10\x06')
'310601'
utils_fmt.plmn_str_to_buf("310160")
b'\x13\x00a'

so the bytes on the wire and from the codec are different.

utils_fmt.plmn_buf_to_str() and utils_fmt.plmn_str_to_buf are relying internally on https://github.com/P1sec/pycrate/blob/839291c8e83719bbd607542273d41eb920a2911b/pycrate_mobile/TS24008_IE.py#L229 which is valid for NAS specification for example:

However PLMNIdentity encoding is different with regards to the digit order:

Perhaps PLMNIdentity should have its own utility codec function ?

[p1-bmu]

I realized few months ago PLMN-ID are not encoded in the same way in the RAN as in the Core, but only for 6-digits PLMN... I forgot to patch corenet. Here is the fix: https://github.com/P1sec/pycrate/commit/8afcfc725ee9c3ac6052510867f5077adb5d2439.

Beware this fix will break under Python2. But I guess it's time to stop with specific support for Python2 now, especially in this corenet part.