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