Garbled description with --nas-get-serving-system

Aleksander Morgado aleksander at aleksander.es
Mon Dec 2 16:27:39 UTC 2019


Hey!

> > Hi, I was wondering had any knowledge of an issue we are seeing. We
> > are
> > connecting to private networks we are running on two different brands
> > of
> > EPC. Then, we are using libqmi to query the modem for the network
> > info via
> > --nas-get-serving-system
>
> 0A:      D4:F2:9C:EE:2C:D3:EF:6F:F9:1A
> ^length  ^ data
>
> So length is 10 bytes, but in ASCII "TestNetwork" is 11 bytes long.
> Hmm. What do we know packs more than one character into each byte...
>
> The string is most likely GSM7 encoded and libqmi is expecting all
> strings in UTF8, which is what almost everything in QMI is reported as.
>
> So my best guess is that the Telit modem firmware is not correctly
> converting the network name to Unicode for us. Every other QMI
> implementation we've seen does :)
>
> ModemManager has some special code to ignore the description when it's
> not UTF-8 safe, and libqmi only does it for printable stuff like what
> qmicli outputs. Perhaps it could work around the Telit firmware
> somehow.
>

Other messages, like "Get Home Network" (0x0025), have a special TLV
indicating the encoding of the network description with the following
supported values:
• 0x00 – Octet, unspecified
• 0x02 – 7-bit ASCII
• 0x04 – Unicode
• 0x09 – GSM 7-bit default

I don't know of any such TLV in "Get Serving System", but maybe
there's a new one we don't know of. There isn't any unknown one in the
provided message as far as I can see.

As Dan said, ModemManager has UTF-8 validity checks before using the
strings, but the printable TLV descriptions in libqmi and the qmicli
output lack that logic.

@Daniele Palmas @Carlo Lobrano do you know if this is a Telit specific
issue or a more generic one? Is the firmware preferring the GSM-7
output for this field over Unicode when the characters fit in GSM-7?

-- 
Aleksander
https://aleksander.es


More information about the libqmi-devel mailing list