Odd QMI devices - ZTE MF60

[Bjørn Mork]

Aleksander Morgado <aleksander at lanedo.com> writes:
>> Time to start adding quirk support :-)
>> 
>> So I've just gone another round with device and finally made some
>> progress.  Sending QMI_CTL "set instance id" will enable the ethernet
>> interface, providing a local DHCP configured and NATed connection using
>> RFC1918 addresses.  Many other QMI commands are supported, including at
>> least one QMI_WDS command, but the normal connection management commands
>> will make the firmware crash.  So this device needs to be treated with
>> special care!
>> 
>> 3G connection management is done using the built-in web server.  Does
>> not look like it can be managed by QMI.  But many QMI_NAS and QMI_DMS
>> commands are supported.
>> 
>> I have no documentation for "set instance id" except the description
>> from Code Aurora and sample usage snooped from the Windows driver.
>> Windows sets TLV 0x01 to a single 0, so that's what I'm using as well:
>> 
>>  01 0f 00 00 00 00 00 00  20 00 04 00 01 01 00 00
>> 
>
> Is there any requirement in when to send this command? Does it need to
> be exactly the first one sent, or can we do version-info checks before
> that? I'll be adding it as a new optional step when opening the QmiDevice.

It doesn't need to be the first one.  The Windows driver does what seems
to be normal device verification first, using QMI_DMS, and that works as
expected.

The only requirements are that
 1) the command must be sent before doing DHCP, and that
 2) almost all QMI_WDS commands must be avoided.

Windows sends only two QMI_WDS commands to this device: 0x0001 and
0x0023.  They are sent immediately after the "set instance id".  They
seem to be optional, as expected.

Those are the only QMI_WDS commands I've seen the device respond to
without crashing, so I believe all other QMI_WDS commands must be
flagged as unsafe for this device.  For example, an "innocent" command
like 0x0022 ("GET_PKT_SRVC_STATUS") will crash the firmware.  So will
any attempt to call 0x0020 ("START_NETWORK_INTERFACE").

I have not seen the device crash on any other subsystem, but I've only
tried the most common QMI_DMS and QMI_NAS commands.

The device will send some QMI_WDS indications, so registering a client
ID and sending 0x0001 to receive them still makes sense.  Windows sets
TLV 0x10 to 1 (report channel rate) and TLV 0x11 to 0 0 0 0 0 (disable
packet statistics):

 0000  01 18 00 00 01 07 00 04  00 01 00 0c 00 10 01 00
 0010  01 11 05 00 00 00 00 00  00

I've no idea if other report settings will work.

Among the unsolicited packets from the device is this one:

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

It has a sane QMUX structure, and does pass as a QMI_WDS indication.
But the 0xf001 msgid is odd and the message content does not look valid.
AFAICS, it's always the same, including what seems to be ascii "4444"

But given that we have no way to figure out what this is, I believe it's
better just ignored.  You should however be prepared to see such non
conforming messages without bugging out...

> Also, any idea what's the 2-byte 'link ID' (TLV 0x01) that we get as
> response? The first byte matches the one we sent as instance ID, but is
> the second one always 0?

No idea.  The lack of documentation and sample code for QMI_CTL is a
problem.  I've only seen 0.  And I cannot figure out what meaning it
could have.


Bjørn