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

[Bjørn Mork <bjorn mork no>]

Aleksander Morgado <aleksander lanedo com> writes:

>> 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.

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.


Bjørn