Modeswitching a ZTE CWID
Markus Gothe
nietzsche at lysator.liu.se
Tue Aug 18 17:00:47 PDT 2015
Björn your assumptions are right! ;-)
I’ll fiddle around with this but apparently according to RF webs sites (and my testing) you get into different mode switches depending on the number,
8 being PID 0x1402 and QMI; 9 gives PID 0x9994 and MBIM-mode but exit very fast…
etc….
//M
On 18 Aug 2015, at 22:16 , Bjørn Mork <bjorn at mork.no> wrote:
> Markus Gothe <nietzsche at lysator.liu.se> writes:
>
>> Found this way to modeswitch a ZTE MF823 CWID to QMI:
>> http://192.168.0.1/goform/goform_set_cmd_process?goformId=USB_MODE_SWITCH&usb_mode=8
>
> Nice :)
>
> I assume you've tried out other likely usb_mode values?
>
>> However on the new PID (0x1402) interfaces 2 and 3 will be in reversed
>> order from what we known from earlier. The QMI interface is hence #3.
>
> Ouch. How do we handle that? I see that the previously known device
> with the 19d2:1402 ID is "my" MF60. It has this descriptor layout:
>
>
> Bus 005 Device 080: ID 19d2:1402 ZTE WCDMA Technologies MSM
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> idVendor 0x19d2 ZTE WCDMA Technologies MSM
> idProduct 0x1402
> bcdDevice 0.00
> iManufacturer 3 ZTE,Incorporated
> iProduct 2 ZTE WCDMA Technologies MSM
> iSerial 4 P680A1ZTED010000
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 108
> bNumInterfaces 4
> bConfigurationValue 1
> iConfiguration 1 ZTE Configuration
> bmAttributes 0xc0
> Self Powered
> MaxPower 500mA
> 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
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> 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 0x82 EP 2 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 0x02 EP 2 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 32
> 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
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 3
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 8 Mass Storage
> bInterfaceSubClass 6 SCSI
> bInterfaceProtocol 80 Bulk-Only
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x04 EP 4 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x85 EP 5 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 0
> Device Qualifier (for other device speed):
> bLength 10
> bDescriptorType 6
> bcdUSB 2.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> bNumConfigurations 1
> Device Status: 0x0000
> (Bus Powered)
>
>
> As you can see, we could detect the QMI interface here by simple
> elimination: There is only one interface with 3 endpoints.
>
> Do you happen to have an lsusb or similar descriptor dump of the MF823
> 19d2:1402 device? Maybe we can find some rule we could apply (possibly
> as a quirk) here to auto-detect the correct QMI interface?
>
> ZTE is definitely *not* making this easy...
>
>
>
> Bjørn
//Markus - The panama-hat hacker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20150819/99a50a1b/attachment.sig>
More information about the libqmi-devel
mailing list