>>>> 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 _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
