Hi Sergey,
This field may not be defined for ISIM in use. In this case the
field still can be read from ISIM, though it will not contain
a valid UTF8 string. For instance, it may contain 255 0xFF bytes.
Ugh, seems like the SIM vendor can't follow RFC's either? 31.103 Section
4.2.2 says:
"For contents and syntax of NAI TLV data object values see IETF RFC 2486
[24]. The NAI shall be encoded to an octet string according to UTF-8
encoding rules as specified in IETF RFC 3629 [27]. The tag value of the NAI
TLV data object shall be '80'. "
This crash occured during my experiments with eSIM. As I mentioned, the
content of that TLV data object was 0xff bytes. IIUC it looks like vendor
could just skip initialization of that particular TLV data object during
bootstrap. Though I am not yet familiar with eSIM init procedure...
I figured. The likely reason for this is that SIM strings are generally encoded
in another format. If you're interested, see src/util.c sim_string_to_utf8().
0xff is used as padding in such cases and thus a field with only 0xffs is
treated as empty.
However, the above would seem not to apply to EFimpi and a few others that 3GPP
wants encoded as a utf-8 string. So, likely, a bug on the SIM, but we should
have sanitized the contents better.
Regards,
-Denis
_______________________________________________
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org
