Odd QMI devices - ZTE MF60

[Bjørn Mork]

Bjørn Mork <bjorn at mork.no> writes:
> Aleksander Morgado <aleksander at lanedo.com> writes:
>
>>> If you want to give it a try, qmicli now supports it as well, e.g.:
>>> $> sudo qmicli -d /dev/cdc-wdm0 \
>>>                --device-open-instance-id=5 \
>>>                --dms-get-manufacturer \
>>>                --verbose
>>> 
>>
>> So, new approach now. Instead of a flag for qmi_device_open(), I
>> prepared a new qmi_device_set_instance_id() which does all the job. Much
>> cleaner as no need to define the instance id value when creating the
>> QmiDevice. qmicli also supports `--device-set-instance-id=X' as well.
>> It's already in libqmi git master, so you can forget about that previous
>> branch.
>
> Looks good.  Makes the MF60 work as expected, as long as I stay away
> from QMI_WDS.  And no QMI_DMS commands seem not crash the firmware, even
> the unsupported ones.

One more observation from this device.  I played with the connection
settings in the web gui while monitoring the QMI interface, and noticed
that I get this when going online (also on when autoconnecting:

  01 1e 00 80 01 ff 04 00 00 01 f0 12 00 01 01 00 02 80 04 00 34 34 34 34 00 00 00 00 00 00 00

and this after disconnecting:

  01 17 00 80 01 ff 04 00 00 01 f0 0b 00 01 01 00 01 00 00 00 00 00 00 00


Those are of course invalid, and I feel pretty sure that's a firmware
bug.  They look too similar to start/stop network messages, having a TLV
0x01 set to 2 for the connected state and 1 for the disconnected
state. And the "34 34 34 34" could be a vendor specific attempt on a
pkt_data_handle.  The 0x80 TLV number is suspicious though.  And the
trailing 0 bytes should probably have been "02 00 04 00 00 00 00",
indicating success (although that is not normal for indications).

If we do that transformation, then they decode as

>>>>>> QMUX:
>>>>>>   length  = 30
>>>>>>   flags   = 0x80
>>>>>>   service = "wds"
>>>>>>   client  = 255
>>>>>> QMI:
>>>>>>   flags       = "indication"
>>>>>>   transaction = 0
>>>>>>   tlv_length  = 18
>>>>>>   message     = (0xf001)
>>>>>> TLV:
>>>>>>   type   = 0x01
>>>>>>   length = 1
>>>>>>   value  = 02
>>>>>> TLV:
>>>>>>   type   = 0x80
>>>>>>   length = 4
>>>>>>   value  = 34:34:34:34
>>>>>> TLV:
>>>>>>   type   = 0x02
>>>>>>   length = 4
>>>>>>   value  = 00:00:00:00

>>>>>> QMUX:
>>>>>>   length  = 23
>>>>>>   flags   = 0x80
>>>>>>   service = "wds"
>>>>>>   client  = 255
>>>>>> QMI:
>>>>>>   flags       = "indication"
>>>>>>   transaction = 0
>>>>>>   tlv_length  = 11
>>>>>>   message     = (0xf001)
>>>>>> TLV:
>>>>>>   type   = 0x01
>>>>>>   length = 1
>>>>>>   value  = 01
>>>>>> TLV:
>>>>>>   type   = 0x02
>>>>>>   length = 4
>>>>>>   value  = 00:00:00:00


I don't know if we want to do anything with these though.  They are
undocumented, vendor specific and buggy.


What can be used is the fact that sending "Set Instance ID" immediately
triggers a Packet Service Status QMI_WDS indication with status
connected, regardless of the actual 3G connection (which kind of makes
sense as the local connection is always available):

>>>>>> QMUX:
>>>>>>   length  = 23
>>>>>>   flags   = 0x80
>>>>>>   service = "ctl"
>>>>>>   client  = 0
>>>>>> QMI:
>>>>>>   flags       = "response"
>>>>>>   transaction = 5
>>>>>>   tlv_length  = 12
>>>>>>   message     = "Set Instance ID" (0x0020)
>>>>>> TLV:
>>>>>>   type       = "Result" (0x02)
>>>>>>   length     = 4
>>>>>>   value      = 00:00:00:00
>>>>>>   translated = SUCCESS
>>>>>> TLV:
>>>>>>   type       = "Link ID" (0x01)
>>>>>>   length     = 2
>>>>>>   value      = 42:00
>>>>>>   translated = 66

>>>>>> QMUX:
>>>>>>   length  = 17
>>>>>>   flags   = 0x80
>>>>>>   service = "wds"
>>>>>>   client  = 255
>>>>>> QMI:
>>>>>>   flags       = "indication"
>>>>>>   transaction = 0
>>>>>>   tlv_length  = 5
>>>>>>   message     = "Get Packet Service Status" (0x0022)
>>>>>> TLV:
>>>>>>   type   = 0x01
>>>>>>   length = 2
>>>>>>   value  = 02:00


This shows up without even registering any QMI_WDS client.  I assume
it's an attempt from the firmware to trick any driver/application into
believing it's already connected, and therefore avoid any connection
attempts.

We could choose to let ourselves beeing tricked here, avoiding any
device specific quirk and just believe the indication instead.  Would
that work?

Yuck, I just noticed a couple more bugs in the firmware's QMI_WDS
interception: It responds (using allowed 0x0001 and 0x0023 commands) to
any client ID, allocated or not.  And it crashes on unknown QMI_WDS
commands instead of responding with QMI_ERR_INVALID_QMI_CMD.

Based on the last observation, I assume that the problem is that the
firmware crashes on any QMI_WDS command it doesn't implement.  And it
doesn't implement many...  It's tempting to guess that a firmware
engineer has observed the Windows driver and implemented exactly those
commands necessary to trick Windows into believing there is a
connection.

You gotta love that development model ;-)



Bjørn