Odd QMI devices - ZTE MF60

[Aleksander Morgado]

>>>> 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.
>>>
>>
>> :-/
> 
> I think I got something after all.
> 
> The Qualcomm chips may support multiple channels, best known from the
> Android drivers I believe.  But there are also USB device firmwares
> supporting this, like the Sierra Wireless MC7710.  It has a mode with 3
> channels.  For some reason I cannot get the third one to work but the
> first two work as expected: You get two QMI/wwan interfaces on the same
> device, mostly looking like they are completely independent of each
> other.  Device settings are of course shared, so this is not entirely
> true, but important services like QMI_CTL and QMI_WDS look like they are
> completely separated.
> 
> Now for the interesting part:  channel 1 always returns 1, while channel
> 0 always returns 0 as seen on other devices.

Does the link ID also include the requested instance ID in your tests?
This is, if you set instance ID '5' in channel 1, does it return '0x05
0x01' ?


> 
> So the additional byte may in fact just be the rmnet channel.  I would
> love to get the third channel working to verify that it returns 2, but I
> don't know what the problem could be.  I don't get any response at all
> to any control message addressed to that interface.  I've tried asking
> on the Sierra forums, but haven't got any meaningful response.  The mode
> is probably completely unsupported and might be completely untested.
> The Windows driver *.inf does not support it.
> 


-- 
Aleksander