Re: [MM 07] Huawei plugin: "Failed to find primary port"

[Aleksander Morgado <aleksander lanedo com>]

>>> ModemManager[11662]: KEY: 06:00:03:02:00:00:00:00
>>> ModemManager[11662]:   Service: 02
>>> ModemManager[11662]:   Client ID: 03
>>> ModemManager[11662]:   Transaction ID: 06:00
>>> ModemManager[11662]: [/dev/cdc-wdm0] Received message...
>>>>>>>>>>>>>>> QMUX:
>>>>>>>>>>>>>>>   length  = 47
>>>>>>>>>>>>>>>   flags   = 0x80
>>>>>>>>>>>>>>>   service = "dms"
>>>>>>>>>>>>>>>   client  = 3
>>>>>>>>>>>>>>> QMI:
>>>>>>>>>>>>>>>   flags       = "response"
>>>>>>>>>>>>>>>   transaction = 6
>>>>>>>>>>>>>>>   tlv_length  = 35
>>>>>>>>>>>>>>>   message     = "Get IDs" (0x0025)
>>>>>>>>>>>>>>> TLV:
>>>>>>>>>>>>>>>   type       = "Result" (0x02)
>>>>>>>>>>>>>>>   length     = 4
>>>>>>>>>>>>>>>   value      = 00:00:00:00
>>>>>>>>>>>>>>>   translated = SUCCESS
>>>>>>>>>>>>>>> TLV:
>>>>>>>>>>>>>>>   type       = "Imei" (0x11)
>>>>>>>>>>>>>>>   length     = 25
>>>>>>>>>>>>>>>   value      = 33:35:33:36:31:33:30:34:38:38:30:35:31:39:39:02:B0:1C:0E:02:84:E3:A6:01:3D
>>>>>>>>>>>>>>>   translated = 353613048805199���=
>>> ModemManager[11662]: KEY: 06:00:03:02:00:00:00:00
>>> ModemManager[11662]:   Service: 02
>>> ModemManager[11662]:   Client ID: 03
>>> ModemManager[11662]:   Transaction ID: 06:00
>>> ModemManager[11662]: <debug> [1346755251.079194] [mm-broadband-modem-qmi.c:797] modem_load_equipment_identifier_finish(): loaded equipment identifier: 353613048805199���=
>>> ModemManager[11662]: <debug> [1346755251.079349] [mm-broadband-modem-qmi.c:924] modem_load_device_identifier(): loading device identifier...
>>> ModemManager[11662]: <debug> [1346755251.079495] [mm-modem-helpers.c:129] mm_create_device_identifier(): Device ID source '000012d100001506353613048805199=8200C-FACPACZQ-103801[Oct14201014:00:00]8QUALCOMMINCORPORATED'
>>> ModemManager[11662]: <debug> [1346755251.079590] [mm-modem-helpers.c:130] mm_create_device_identifier(): Device ID 'acf85b48ca4510376b6ca51f7cc9ba99f07e4bbf'
>>> ModemManager[11662]: <debug> [1346755251.079703] [mm-broadband-modem-qmi.c:912] modem_load_device_identifier_finish(): loaded device identifier: acf85b48ca4510376b6ca51f7cc9ba99f07e4bbf
>>>
>>>
>>> Which is very odd.  Attempting to run 
>>>
>>>   qmicli -d /dev/cdc-wdm0 -v --dms-get-ids
>>>
>>> consistenly result in:
>>>
>>> [04 Sep 2012, 13:01:55] [Debug] [/dev/cdc-wdm0] Received message...
>>>>>>>>>>>>>>> QMUX:
>>>>>>>>>>>>>>>   length  = 38
>>>>>>>>>>>>>>>   flags   = 0x80
>>>>>>>>>>>>>>>   service = "dms"
>>>>>>>>>>>>>>>   client  = 10
>>>>>>>>>>>>>>> QMI:
>>>>>>>>>>>>>>>   flags       = "response"
>>>>>>>>>>>>>>>   transaction = 1
>>>>>>>>>>>>>>>   tlv_length  = 26
>>>>>>>>>>>>>>>   message     = "Get IDs" (0x0025)
>>>>>>>>>>>>>>> TLV:
>>>>>>>>>>>>>>>   type       = "Result" (0x02)
>>>>>>>>>>>>>>>   length     = 4
>>>>>>>>>>>>>>>   value      = 00:00:00:00
>>>>>>>>>>>>>>>   translated = SUCCESS
>>>>>>>>>>>>>>> TLV:
>>>>>>>>>>>>>>>   type       = "Imei" (0x11)
>>>>>>>>>>>>>>>   length     = 16
>>>>>>>>>>>>>>>   value      = 33:35:33:36:31:33:30:34:38:38:30:35:31:39:39:02
>>>>>>>>>>>>>>>   translated = 353613048805199
>>>
>>>
>>> So you still got a bogus 0x02 byte there, but why did MM see 9 more
>>> bytes?  Anyway, it is safe to consider any firmware response as
>>> potentionally buggy, and never trust any of it to fit into any expected
>>> pattern...
>>>
>>> Yes, I know that's easy to say ;-)
>>
>> I believe Dan already had this issue a couple of weeks ago.
>>
>> The main issue here is that the 'length' value of the TLV is clearly
>> wrong. In all cases it should have been '15'. We just get a greater
>> value and we end up reading more transferred data which probably means
>> nothing.
> 
> Whether the length is wrong can be discussed.  It matches the amount of
> data the device sends.  The driver won't pad the data in any way, so you
> wouldn't read anything if the length was wrong.  So the device sends too
> much data, but formats it as a valid message. Could e.g. be caused by
> some part of the firmware expecting a 0 terminated IMEI string and
> another part sending the IMEI as a char[15] and expecting any user to
> know it is limited to 15 bytes.
> 
>> We can try to avoid this by making libqmi-glib validate every output
>> 'string' variable as valid UTF-8 (or even ASCII?). Not sure which is the
>> default expected encoding in QMI, but at least this check will make us
>> provide always safe values which we can then use in DBus.
> 
> If the IMEI is the only place where this happens, then it is possible to
> work around it as you know that a valid one always will be exactly 15
> ASCII digits.

We could impose that limit in libqmi-glib, by re-using the "max-size"
key, which was meant to be used in input variables only. A "max-size"
given in an output string would just trim the read data to the given
maximum size.

> 
> But in general I don't think we can validate *all* TLVs like this. It
> will have to be a case-by-case consideration based on how important the
> value is, if related firmware bugs have been observed, and how easy we
> can validate the value.
> 

Well, MM will anyway need to validate any string retrieved to be valid
UTF-8, at least if we want to put it in the DBus API. The criticals that
you saw were just because of the built-in UTF-8 validation on strings to
be passed through DBus.

I'll hack the 'max-size' parameter for output strings and put it in the
IMEI, as that is really a safe case.

-- 
Aleksander