Aleksander Morgado <aleksan...@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 _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list