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



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

Just pushed some commits in libqmi to handle this issue.

-- 
Aleksander


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]