Weird QMI devices - ZTE MF60
Dan Williams
dcbw at redhat.com
Tue Mar 6 11:07:26 PST 2012
On Sat, 2012-03-03 at 15:08 +0100, Bjørn Mork wrote:
> Better bring some noise to this list instead of overloading the
> linux-usb list with irrelevant QMI discussions :-)
>
> Someone borrowed med a ZTE MF60 "Global Mobile Hotspot". Nice thing
> with a battery, 3G and WiFi. Works just as standalone 3G <-> WiFi
> bridge. But that's irrelant here.
>
> The device also has a USB interface which normally exposes a storage
> interface with the usual Windows driver CDROM using 19d2:2000 as ID.
> usb_modeswitch didn't pick it up, but doing "eject /dev/srX" switches
> the device to ID 19d2:1402 where we get three interfaces which are
> picked up by the option driver. Only one of these seem to speak AT
> commands. And one of those which do not looks very interesting:
>
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 0
> bNumEndpoints 3
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 255 Vendor Specific Subclass
> bInterfaceProtocol 255 Vendor Specific Protocol
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 5
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 32
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 32
>
>
> So I added the device to my qmi_wwan driver to get this exposed as a
> combined net/QMI interface. Don't know about the net part yet - might
> be just that it runs in raw IP mode - but this interface does certainly
> speak QMI embedded in CDC.
>
> QMI_DMS and QMI_NAS commands work just fine. E.g.:
>
> sending to /dev/cdc-wdm2:
> 01 0c 00 00 02 01 00 03 00 21 00 00 00
> => QMUX Header:
> => len: 0x000c
> => sender: 0x00
> => svc: 0x02
> => cid: 0x01
>
> => QMI Header:
> => Flags: 0x00
> => TXN: 0x0003
> => Cmd: 0x0021
> => Size: 0x0000
> reading from /dev/cdc-wdm2
> read 44 bytes from /dev/cdc-wdm2
> 01 2b 00 80 02 01 02 03 00 21 00 1f 00 02 04 00 00 00 00 00 01 15 00 51 55 41 4c 43 4f 4d 4d 20 49 4e 43 4f 52 50 4f 52 41 54 45 44
> <= QMUX Header:
> <= len: 0x002b
> <= sender: 0x80
> <= svc: 0x02
> <= cid: 0x01
>
> <= QMI Header:
> <= Flags: 0x02
> <= TXN: 0x0003
> <= Cmd: 0x0021
> <= Size: 0x001f
> <= [0x01] (21) 51 55 41 4c 43 4f 4d 4d 20 49 4e 43 4f 52 50 4f 52 41 54 45 44 QUALCOMM INCORPORATED
> <= [0x02] ( 4) 00 00 00 00 SUCCESS - QMI_ERR_NONE
>
> sending to /dev/cdc-wdm2:
> 01 0c 00 00 02 01 00 04 00 23 00 00 00
> => QMUX Header:
> => len: 0x000c
> => sender: 0x00
> => svc: 0x02
> => cid: 0x01
>
> => QMI Header:
> => Flags: 0x00
> => TXN: 0x0004
> => Cmd: 0x0023
> => Size: 0x0000
> reading from /dev/cdc-wdm2
> read 74 bytes from /dev/cdc-wdm2
> 01 49 00 80 02 01 02 04 00 23 00 3d 00 02 04 00 00 00 00 00 01 33 00 4d 38 32 30 30 43 2d 46 41 43 50 41 43 5a 44 2d 31 2e 30 2e 33 39 32 54 20 20 31 20 20 5b 53 65 70 20 32 31 20 32 30 31 31 20 31 36 3a 33 35 3a 30 39 5d
> <= QMUX Header:
> <= len: 0x0049
> <= sender: 0x80
> <= svc: 0x02
> <= cid: 0x01
>
> <= QMI Header:
> <= Flags: 0x02
> <= TXN: 0x0004
> <= Cmd: 0x0023
> <= Size: 0x003d
> <= [0x01] (51) 4d 38 32 30 30 43 2d 46 41 43 50 41 43 5a 44 2d 31 2e 30 2e 33 39 32 54 20 20 31 20 20 5b 53 65 70 20 32 31 20 32 30 31 31 20 31 36 3a 33 35 3a 30 39 5d M8200C-FACPACZD-1.0.392T 1 [Sep 21 2011 16:35:09]
> <= [0x02] ( 4) 00 00 00 00 SUCCESS - QMI_ERR_NONE
> got match!
>
>
>
> But QMI_WDS commands have an interesting effect: They make the device
> switch from this:
>
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 108
> bNumInterfaces 4
> bConfigurationValue 1
> iConfiguration 1 ZTE Configuration
> bmAttributes 0xc0
> Self Powered
> MaxPower 500mA
>
> to this:
>
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 32
> bNumInterfaces 1
> bConfigurationValue 1
> iConfiguration 1 Qualcomm Configuration
> bmAttributes 0xe0
> Self Powered
> Remote Wakeup
> MaxPower 500mA
>
>
>
> But I have no idea how to use the latter. The single interface provided
> have only bulk in/out endpoints, so the usual CDC embedded QMI is
> impossible. And it doesn't seem to support ethernet either. This
> interface descriptor is:
>
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 255 Vendor Specific Subclass
> bInterfaceProtocol 255 Vendor Specific Protocol
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 32
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x01 EP 1 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 32
>
>
> So now I wonder what all this is about... Having driver support for
> exposing the QMI protocol of the device would be useful, but the
> unexpected mode switch makes me worry. And I haven't found any way to
> switch it back to something useful either. Have to disconnect it and
> remove the battery to make it reset. That isn't very user friendly.
>
> Has anyone seen something like this before? What should we do about
> it?
That's pretty bizarre, and I've never heard of anything like that. So
when in "Qualcomm" mode it really only has one usb interface? Maybe
that's a firmware loading interface or something? Not really sure; but
the Gobi modems only expose one or two interfaces when in firmware
download mode and after you download the firmware they switch to
4-interface mode. About the only thing I can think of is to run
'strings' on the Windows connection manager and drivers and see if the
driver does do anything with QMI, that usually shows up in the binaries.
Any chance you can tar up the fake CD that it exposes before modeswitch
and send it to me for inspection?
Dan
More information about the libqmi-devel
mailing list