Odd QMI devices - ZTE MF60

[Aleksander Morgado]

>>> 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.
> 

Then it's probably better not to implement it as a flag when opening the
device, and just hack a new independent method for it.


> 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.
> 

For this kind of device-specific behaviour, I guess we can pass the
VID/PID when creating the QmiDevice (or get it ourselves internally),
and then implement a blacklist of requests, so that if we try to use a
given request in those devices we get an early error before sending the
request to the device. Similar to the idea of specifying the service
version when each request was introduced, and give an error if trying to
use the request in an older version of the service.


> 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...

I'll check that.

> 
>> 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.
> 

:-/

Cheers!

-- 
Aleksander