Activation Codes and Methods, Hardware Details, Sniffing
copyninja
Posts: 8
Joined: Thu Aug 29, 2013 6:40 pm

Switching problem with ZTE MF825A 4G LTE Device (Airtel)

Post by copyninja » Thu Aug 29, 2013 7:15 pm

Hi all,

I recently purchased a 4G LTE Dongle from Airtel (provider in India) the manufacture of dongle is ZTE and Model is MF825A seems specific to Airtel only for now. The device is detected with following ID's on Windoze

USB\VID_19D2&PID_1225&REV_?07< : Before installing Driver
USB\VID_19D2&PID_1403&REV_?07< : After installing Driver

On Linux the product Id for devices is 19d2:1408 but I don't see any ttyUSB devices getting created. I tried the crappy software provided by ZTE for Linux which was not straight forward to use after toying around got it running but it does not detect device :x Here is the lsusb output for device

Code: Select all

Bus 002 Device 010: ID 19d2:1408 ZTE WCDMA Technologies MSM 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x19d2 ZTE WCDMA Technologies MSM
  idProduct          0x1408 
  bcdDevice           f0.7c
  iManufacturer           2 
  iProduct                3 
  iSerial                 4 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          103
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      6 Ethernet Networking
      bInterfaceProtocol      0 
      iInterface              5 
      CDC Header:
        bcdCDC               1.10
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      CDC Ethernet:
        iMacAddress                      7 (??)
        bmEthernetStatistics    0x00000000
        wMaxSegmentSize               1514
        wNumberMCFilters            0x0000
        bNumberPowerFilters              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               9
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              6 
      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               0
      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               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        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     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
Weirdly enough device even provides me an ethernet interface :?: I went ahead to get the usb sniffer working and attaching the UsbSnoop.log with this mail. I took the first switching entry from the log because I was not sure if its the correct one or not. Below I'm pasting 19d2:1225 file I placed under /etc/usb_modeswitch.d/ (yes I use Debian unstable)

Code: Select all

DefaultVendor = 0x19d2
DefaultProduct = 0x1225

MessageEndpoint = 0x01
MessageContent = "55534243a8e909812400000080000612000000240000000000000000000000"
And I created a udev rule file pasted below

Code: Select all

SUBSYSTEM=="usb", ATTR{idProduct}=="1225", ATTR{idVendor}=="19d2", \
		  RUN+="/usr/sbin/usb_modeswitch -c /etc/usb_modeswitch.d/19d2:1225"
After this below is the dmesg output I still can't see ttyUSB or any other serial interface :(

Code: Select all

[ 2733.174428] usb 2-1.1: new high-speed USB device number 11 using ehci-pci
[ 2733.293878] usb 2-1.1: New USB device found, idVendor=19d2, idProduct=1225
[ 2733.293889] usb 2-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=4
[ 2733.293896] usb 2-1.1: Product: ZTE WCDMA Technologies MSM
[ 2733.293902] usb 2-1.1: Manufacturer: ZTE,Incorporated
[ 2733.293907] usb 2-1.1: SerialNumber: MF8250ZTED000000
[ 2733.311418] usb-storage 2-1.1:1.0: USB Mass Storage device detected
[ 2733.311546] scsi16 : usb-storage 2-1.1:1.0
[ 2733.517383] usb 2-1.1: usbfs: process 20661 (usb_modeswitch) did not claim interface 0 before use
[ 2738.673220] usb 2-1.1: USB disconnect, device number 11
[ 2738.934875] usb 2-1.1: new high-speed USB device number 12 using ehci-pci
[ 2739.054314] usb 2-1.1: New USB device found, idVendor=19d2, idProduct=1408
[ 2739.054324] usb 2-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=4
[ 2739.054331] usb 2-1.1: Product: ZTE WCDMA Technologies MSM
[ 2739.054337] usb 2-1.1: Manufacturer: ZTE,Incorporated
[ 2739.054342] usb 2-1.1: SerialNumber: MF8250ZTED000000
[ 2739.072924] cdc_ether 2-1.1:1.0 eth1: register 'cdc_ether' at usb-0000:00:1d.0-1.1, CDC Ethernet Device, 34:4b:50:b7:ef:4a
[ 2739.073752] usb-storage 2-1.1:1.2: USB Mass Storage device detected
[ 2739.073891] scsi17 : usb-storage 2-1.1:1.2
[ 2740.072229] scsi 17:0:0:0: CD-ROM            CWID     USB SCSI CD-ROM  2.31 PQ: 0 ANSI: 2
[ 2740.072663] scsi 17:0:0:1: Direct-Access     ZTE      MMC Storage      2.31 PQ: 0 ANSI: 2
[ 2740.087912] sr1: scsi-1 drive
[ 2740.088194] sr 17:0:0:0: Attached scsi CD-ROM sr1
[ 2740.088751] sr 17:0:0:0: Attached scsi generic sg2 type 5
[ 2740.091977] sd 17:0:0:1: Attached scsi generic sg4 type 0
[ 2740.093717] sd 17:0:0:1: [sdb] Attached SCSI removable disk
I'm also attaching couple of udev rules file I found installed by the Linux software shipped by ZTE which I later removed along with this post. If any further rule is required from my side please let me know :)

If some one can help me to get this device working I will really be greatful to you :)
Attachments
9-cdrom.txt
cdrom rules shipped zte
(2.7 KiB) Downloaded 533 times
7-zte-multi-port-device.txt
ZTE shipped udev rule
(6.33 KiB) Downloaded 617 times
UsbSnoop.log.gz
UsbSnoop log
(116.06 KiB) Downloaded 631 times

LOM
Posts: 1306
Joined: Wed Jul 11, 2012 3:14 pm
Location: Koh Samui, TH

Re: Switching problem with ZTE MF825A 4G LTE Device (Airtel)

Post by LOM » Fri Aug 30, 2013 4:34 am

Your dongle switches mode with that message but it is not a common switch message for ZTE devices.
If you check the other 19d2 devices under /etc/usb_modeswitch.d then you will see that there are 3 types of modeswitch for
ZTE, a single message modeswitch, a dual message modeswitch, and (for a few devices only) a triple message modeswitch.

Try these 3 ZTE standard switching methods in your 19d1:1225 config file, observe that you must add NeedResponse=1 for a configuration with more than 1 message.
Can you get it to switch with any of these 3 methods?

19d2:1408, which you got after sending the message you found in the log does not have any serial interfaces, only a direct ethernet interface which you also can see from the dmesg.

19d2:1403, the id from Windows, may have a different interface layout and may have serial interfaces, that is the reason I ask you to try the 3 common ZTE switch methods.


You can also try to use 55534243123456782000000080000c85010101180101010101000000000000 as switch message,
another ZTE device with initial id 19d2:1225 (same as yours) does switch with that message.

copyninja
Posts: 8
Joined: Thu Aug 29, 2013 6:40 pm

Re: Switching problem with ZTE MF825A 4G LTE Device (Airtel)

Post by copyninja » Fri Aug 30, 2013 7:30 pm

LOM wrote: You can also try to use 55534243123456782000000080000c85010101180101010101000000000000 as switch message,
another ZTE device with initial id 19d2:1225 (same as yours) does switch with that message.
Well how did you get this message content? actually I didn't find any file by name 19d2:1225 in usb-mode-switch data recent one (20130803). but coming to the point this worked! Here is my updated config

Code: Select all

DefaultVendor=0x19d2
DefaultProduct=0x1225

#TargetVendor= 0x19d2
#TargetProduct= 0x1403

MessageEndpoint=0x01
MessageContent="55534243288428862400000080000612000000240000000000000000000000"   
MessageContent2="55534243123456782000000080000c85010101180101010101000000000000"
NeedsResponse=1
Even though it switches the device to 0x1403 product id its not serial interface as I was expecting it but it converts the device into an rndis host. I cross checked this on Window there also software uses rndis host. here is updated lsusb output

Code: Select all


Bus 002 Device 029: ID 19d2:1403 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          0x1403 
  bcdDevice           f0.7c
  iManufacturer           2 
  iProduct                3 
  iSerial                 4 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           98
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              500mA
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         0
      bInterfaceCount         2
      bFunctionClass        224 Wireless
      bFunctionSubClass       1 Radio Frequency
      bFunctionProtocol       3 RNDIS
      iFunction               7 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol    255 Vendor Specific (MSFT RNDIS?)
      iInterface              5 
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x00
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               9
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              6 
      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               0
      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               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        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     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
First I was not sure how to connect to internet but when I launched network manager I noticed it detected auto network I clicked on connect and it brought up eth1 with 192.168.0.144 and then I launched the shipped binary and it was happy and found device and I was able to connect!. now I'm online from this device.

I'm yet to figure out how I can connect without the crappy software given by Airtel. If you have any clue on how dialing works on rndis please let me know.

Thanks again :-)

Josh
Site Admin
Posts: 6545
Joined: Sat Nov 03, 2007 12:30 am

Re: Switching problem with ZTE MF825A 4G LTE Device (Airtel)

Post by Josh » Fri Aug 30, 2013 11:02 pm

I think you can leave out the first MessageContent line (the one with "0612") from your configuration. This is a standard query for device specifics - it's part of every USB device discovery and certainly not a command to switch modes.

LOM
Posts: 1306
Joined: Wed Jul 11, 2012 3:14 pm
Location: Koh Samui, TH

Re: Switching problem with ZTE MF825A 4G LTE Device (Airtel)

Post by LOM » Sat Aug 31, 2013 5:46 am

Josh wrote:I think you can leave out the first MessageContent line (the one with "0612") from your configuration. This is a standard query for device specifics - it's part of every USB device discovery and certainly not a command to switch modes.
Yes I agree that this is not a message (SCSI command) intended for switching mode but I also know of mfgrs using other fishy SCSI commands for switching their devices, one of them being cmd 85 (ATA PASS THROUGH).
copyninja did somehow get the dongle to switch into 19d2:1408..

copyninja wrote:
LOM wrote: You can also try to use 55534243123456782000000080000c85010101180101010101000000000000 as switch message,
another ZTE device with initial id 19d2:1225 (same as yours) does switch with that message.
Well how did you get this message content? actually I didn't find any file by name 19d2:1225 in usb-mode-switch data recent one (20130803).
It is the last message in a sequence of 3 messages for some ZTE devices.
You should not look for 19d2:1225 in the usb_modeswitch data package, look for any 19d2:xxxx and you will find that there are
3 types of switching methods.
19d2:1225 is a new id for ZTE, I have known about it for a few weeks and was going to ask Josh to include it.
I was not sure about the best modeswitch message/messages for it so it has been on hold.

copyninja wrote:
Even though it switches the device to 0x1403 product id its not serial interface as I was expecting it but it converts the device into an rndis host. I cross checked this on Window there also software uses rndis host.
There are 2 schools, one saying that linux should mimic Windows and use the modeswitch message which windows uses, the other one (which I subscribe to) says that we should find the best modeswitch for linux.
We are often forced to use the windows modeswitch message since users does the USB logging under windows but windows mode is not always optimal for linux.
Huawei for instance has proposed 3 different modeswitch messages for their dongles, one for windows, one for mac, and one for linux.


Your dongle has 2 different resulting id's, 19d2:1408 with ethernet classed interfaces (can probably speak QMI which is even better than cdc_ether) and 19d2:1403 which is Microsoft RNDIS.
The linux rndis_host driver is far from perfect, it is developed from what is known of Microsfts proprietary rndis protocol so in this case I'd say it is much preferred to switch the dongle into 19d2:1408 in linux.

So, how did you manage to get it into 19d2:1408? Did you issue an eject cd-rom cmd from the linux cmd line or was it really only that SCSI INQUERY msg (06 12) doing the switch?

Can you please take another look into the 19d2 files in the data package, find the single message, the dual message, and the triple message and test all 3 methods to see what resulting id (and interface layout) you get when using them.

copyninja
Posts: 8
Joined: Thu Aug 29, 2013 6:40 pm

Re: Switching problem with ZTE MF825A 4G LTE Device (Airtel)

Post by copyninja » Sat Aug 31, 2013 9:02 am

Josh wrote:I think you can leave out the first MessageContent line (the one with "0612") from your configuration. This is a standard query for device specifics - it's part of every USB device discovery and certainly not a command to switch modes.
Yes the config file works without this line. Thanks!

copyninja
Posts: 8
Joined: Thu Aug 29, 2013 6:40 pm

Re: Switching problem with ZTE MF825A 4G LTE Device (Airtel)

Post by copyninja » Sat Aug 31, 2013 9:20 am

LOM wrote: Yes I agree that this is not a message (SCSI command) intended for switching mode but I also know of mfgrs using other fishy SCSI commands for switching their devices, one of them being cmd 85 (ATA PASS THROUGH).
copyninja did somehow get the dongle to switch into 19d2:1408..
I cross checked I did nothing it got switched by itself to 19d2:1408. I removed all ZTE shipped and my udev rules etc. And tried it just switched.

LOM wrote: It is the last message in a sequence of 3 messages for some ZTE devices.
You should not look for 19d2:1225 in the usb_modeswitch data package, look for any 19d2:xxxx and you will find that there are
3 types of switching methods.
19d2:1225 is a new id for ZTE, I have known about it for a few weeks and was going to ask Josh to include it.
I was not sure about the best modeswitch message/messages for it so it has been on hold.
I see it actually works and converts it to RNDIS host just like windows!
LOM wrote: There are 2 schools, one saying that linux should mimic Windows and use the modeswitch message which windows uses, the other one (which I subscribe to) says that we should find the best modeswitch for linux.
We are often forced to use the windows modeswitch message since users does the USB logging under windows but windows mode is not always optimal for linux.
Huawei for instance has proposed 3 different modeswitch messages for their dongles, one for windows, one for mac, and one for linux.


Your dongle has 2 different resulting id's, 19d2:1408 with ethernet classed interfaces (can probably speak QMI which is even better than cdc_ether) and 19d2:1403 which is Microsoft RNDIS.
The linux rndis_host driver is far from perfect, it is developed from what is known of Microsfts proprietary rndis protocol so in this case I'd say it is much preferred to switch the dongle into 19d2:1408 in linux.

So, how did you manage to get it into 19d2:1408? Did you issue an eject cd-rom cmd from the linux cmd line or was it really only that SCSI INQUERY msg (06 12) doing the switch?
I agree with you and I'm also not fan of many windows mode tools / hardware for eg. MTP used by some of Google phones but its OT here. I think ZTE has this mode 19d2:1408 specifically for Linux only , but I can't confirm about Mac.

Actually I didn't do anything probably one of the existing usb_modeswitch rules worked! On Debian its bit different how usb_modeswitch works, I see a udev rules file shipped with package but no data files present under /etc/usb_modeswitch.d :?

So really not sure how switch happened. :) If you have some methods which can tell us this I'm ready to execute them and give you output.

And yeah 1408 also connect to interent. Again it shows up eth1 interface I click on connect for that interface to get a 192.168.0.144 IP and after that software from ZTE can connect to internet. Also I would like to know what is QMI you mentioned above.
LOM wrote: Can you please take another look into the 19d2 files in the data package, find the single message, the dual message, and the triple message and test all 3 methods to see what resulting id (and interface layout) you get when using them.
Yeah sure I will try with them and see what new devices show up and I will provide the lsusb output of resulting layout. I will update as soon as I've some results. Thanks again.

copyninja
Posts: 8
Joined: Thu Aug 29, 2013 6:40 pm

Re: Switching problem with ZTE MF825A 4G LTE Device (Airtel)

Post by copyninja » Sat Aug 31, 2013 10:31 am

Ok I tried 2 message 3 message and 1 message from some files for ZTE. I randomly picked those below is what my conf looks

Code: Select all

DefaultVendor=0x19d2
DefaultProduct=0x1225

# 19d2:2000
# MessageContent="5553424312345678000000000000061e000000000000000000000000000000"
# MessageContent2="5553424312345679000000000000061b000000020000000000000000000000"
# MessageContent3="55534243123456702000000080000c85010101180101010101000000000000"

# 19d2:1224
# MessageContent="5553424312345678000000000000061e000000000000000000000000000000"
# MessageContent2="5553424312345679000000000000061b000000020000000000000000000000"

# 19d2:1227
MessageContent="5553424312345678000000000000061b000000020000000000000000000000"

NeedResponse=1
First I tried with 3 then commented it then used 2 and then commented it and finally used 1. In all cases device switched to 19d2:1403 the Windows RNDIS device. So now I'm just wondering how device switched to 19d2:1408 without any configuration :?

@LOM if you want any more info please let me know.

LOM
Posts: 1306
Joined: Wed Jul 11, 2012 3:14 pm
Location: Koh Samui, TH

Re: Switching problem with ZTE MF825A 4G LTE Device (Airtel)

Post by LOM » Sat Aug 31, 2013 11:07 am

You did unplug-replug the dongle between each try so that it returned to its initial id 19d2:1225 ?
It can't switch if it already is switched.

Here is another device with the same id:
http://www.draisberghof.de/usb_modeswit ... .php?t=924

He could switch it to 19d2:1408 by doing the linux cmd line eject /dev/sr0 (or whatever device name gets created when the dongle is in initial mode/cd-rom mode).

The modeswitch message containing 06 1b is a SCSI "media eject" command and some dongles needs to have it preceded by the 06 1e "prevent/allow media removal" command.
The single message or dual message sending should be equivalent to the cmd eject /dev/sr0 .
The tripple message is both of the above plus the 0c 85 message which I guess is the windows mode selection.


QMI is Qualcom's management protocol for which linux recently has got a driver (qmi_wwan) which creates a direct ethernet device. Difference between qmi_wwan, cdc_ether, and rndis_host is that with qmi you have a known command protocol with linux library support. It is preferred over rndis_host right now but that may change the day we get a better rndis_host driver in linux.

Our local QMI expert (and creator of the linux qmi_wwan driver) Bjorn Mork will surely be here wanting you to try the qmi_wwan driver if you can find out how to get it into 19d2:1408 again.

bmork
Posts: 167
Joined: Thu Mar 15, 2012 10:47 pm
Location: Oslo, Norway

Re: Switching problem with ZTE MF825A 4G LTE Device (Airtel)

Post by bmork » Sat Aug 31, 2013 2:32 pm

LOM wrote:QMI is Qualcom's management protocol for which linux recently has got a driver (qmi_wwan) which creates a direct ethernet device. Difference between qmi_wwan, cdc_ether, and rndis_host is that with qmi you have a known command protocol with linux library support. It is preferred over rndis_host right now but that may change the day we get a better rndis_host driver in linux.

Our local QMI expert (and creator of the linux qmi_wwan driver) Bjorn Mork will surely be here wanting you to try the qmi_wwan driver if you can find out how to get it into 19d2:1408 again.
Well, actually I am lurking here to find out where this all goes.

Some of the newer ZTE devices (at least the MF823) are odd. The firmware will/may/can switch modes by itself based on some idea it has about operating system and drivers. And there are more modes than ever. Expect to see
  • - usb-storage (unswitched)
    - Microsoft RNDIS (legacy Windows 7 and older)
    - CDC ECM (Mac? and Linux?)
    - CDC MBIM (Windows 8)
in some combination. The MBIM function (if any) is probably available in the same device ID as the unswitched mode because of Windows8 requirements. But we haven't yet figured out how to use in in Linux because the firmware switches away from it if you select it on anything but Windows8. Don't know if this is the same on the MF825? Would be interesting to see a full "lsusb -vd 19d2:1225" for the unswitched mode.

There's a partial explanation of the MF823 behaviour from ZTE here:
http://forums.whirlpool.net.au/forum-re ... &p=16#r306

So I am waiting to see if anyone with such a modem can figure out how to switch it to the most usable mode in a reliable way. I consider this the preference from best to worst: MBIM > QMI > ECM > RNDIS, based on our abilities to manage the device. MBIM has a standardized management protocol and wins over the proprietary and ever changing QMI based on that. ECM and RNDIS management is probably via a built-in http server only, making it likely to require device specific management.

Josh
Site Admin
Posts: 6545
Joined: Sat Nov 03, 2007 12:30 am

Re: Switching problem with ZTE MF825A 4G LTE Device (Airtel)

Post by Josh » Sun Sep 01, 2013 12:15 am

Does that mean someone has to do the sniffing on Windows 8?

copyninja
Posts: 8
Joined: Thu Aug 29, 2013 6:40 pm

Re: Switching problem with ZTE MF825A 4G LTE Device (Airtel)

Post by copyninja » Sun Sep 01, 2013 9:24 am

LOM wrote:You did unplug-replug the dongle between each try so that it returned to its initial id 19d2:1225 ?
It can't switch if it already is switched.

Here is another device with the same id:
http://www.draisberghof.de/usb_modeswit ... .php?t=924

He could switch it to 19d2:1408 by doing the linux cmd line eject /dev/sr0 (or whatever device name gets created when the dongle is in initial mode/cd-rom mode).

The modeswitch message containing 06 1b is a SCSI "media eject" command and some dongles needs to have it preceded by the 06 1e "prevent/allow media removal" command.
The single message or dual message sending should be equivalent to the cmd eject /dev/sr0 .
The tripple message is both of the above plus the 0c 85 message which I guess is the windows mode selection.
I replugged the device every time I tried new message. And also I can always see the /dev/sr1 (in my case /dev/sr0 is onboard dvd drive) if I open Thunar file manager. Ejecting it has no affect on device. I think as Bjorn says device detects Linux and automatically switches to 19d2:1408
LOM wrote: QMI is Qualcom's management protocol for which linux recently has got a driver (qmi_wwan) which creates a direct ethernet device. Difference between qmi_wwan, cdc_ether, and rndis_host is that with qmi you have a known command protocol with linux library support. It is preferred over rndis_host right now but that may change the day we get a better rndis_host driver in linux.

Our local QMI expert (and creator of the linux qmi_wwan driver) Bjorn Mork will surely be here wanting you to try the qmi_wwan driver if you can find out how to get it into 19d2:1408 again.
Oh it always switches to 19d2:1408 always without doing anything. So if Bjorn wants me to try qmi_wwan driver I can try that. And also 1408 connects to interent on Linux in similar ways like windows. I can see cdc_ether requires rndis kernel module in lsmod output.
bmork wrote: Would be interesting to see a full "lsusb -vd 19d2:1225" for the unswitched mode.
Here it comes :)

Code: Select all


Bus 001 Device 013: ID 19d2:1225 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          0x1225 
  bcdDevice           f0.7c
  iManufacturer           2 
  iProduct                3 
  iSerial                 4 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              1 
      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               0
      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               1
Josh wrote: Does that mean someone has to do the sniffing on Windows 8?
My neighbour has a Windows 8 laptop so I can try this if SniffUSB works there. But I can't actually guarantee that I will be able to provide the logs :)

Also one more question is UsbPcap log is useful compared to SniffUsb logs?

bmork
Posts: 167
Joined: Thu Mar 15, 2012 10:47 pm
Location: Oslo, Norway

Re: Switching problem with ZTE MF825A 4G LTE Device (Airtel)

Post by bmork » Sun Sep 01, 2013 10:38 am

copyninja wrote:
bmork wrote: Would be interesting to see a full "lsusb -vd 19d2:1225" for the unswitched mode.
Here it comes :)

Code: Select all


Bus 001 Device 013: ID 19d2:1225 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          0x1225 
  bcdDevice           f0.7c
  iManufacturer           2 
  iProduct                3 
  iSerial                 4 
  bNumConfigurations      1
  
Thanks. So only a single storage device and no configuration MBIM there. This device is obviously different from the MF823 in this regard.
Also one more question is UsbPcap log is useful compared to SniffUsb logs?
I can of course not answer for Josh, but I find the UsbPcap logs very useful because you can throw every wireshark dissector at them on any platform supported by wireshark. UsbPcap looks like a nice tool to me. Great to see this kind of open source development for Windows. I often feel that they lag behind the more open operating systems feature-wise, but tools like this helps a lot.

Josh
Site Admin
Posts: 6545
Joined: Sat Nov 03, 2007 12:30 am

Re: Switching problem with ZTE MF825A 4G LTE Device (Airtel)

Post by Josh » Mon Sep 02, 2013 8:17 am

SniffUSB's output is easy to read with no additional tool involved, but AFAIK it doesn't work on Windows above XP ...

So - whatever works is good.

monil.patel
Posts: 2
Joined: Fri Oct 21, 2011 6:47 am

Re: Switching problem with ZTE MF825A 4G LTE Device (Airtel)

Post by monil.patel » Wed Sep 04, 2013 3:53 pm

Hi,
I have tried "usb_modeswitch -v 0x19d2 -p 0x1225 -d"
and it got switched to
T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=19d2 ProdID=1408 Rev=f0.7c
S: Manufacturer=ZTE,Incorporated
S: Product=ZTE WCDMA Technologies MSM
S: SerialNumber=MF8250ZTED000000
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=(none)
E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms
I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=(none)
I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=(none)
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=125us

Post Reply