Unable to access USB storage of ZTE Blade Android phone

The attachment "Patch for 40-usb_modeswitch.rules" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

The simple removal of the device line may break other devices with the same ID.

A better approach would be to find out which ZTE phone needs the switching in any case and which doesn't. usb_modeswitch can distinguish between devices even if the ID is identical; for this purpose we have to find device-specific attributes.

A run of "usb_modeswitch -v 0x19d2 -p 0x0083" with the *unswitched* device present will report the most important USB and SCSI attributes.

What is the behaviour with Windows? Are there any drivers present on the device that will install automatically if the phone is plugged in?

$ sudo usb_modeswitch -v 0x19d2 -p 0x0083

Looking for default devices ...
 Found devices in default mode, class or configuration (1)
Accessing device 002 on bus 001 ...
Getting the current device configuration ...
 OK, got current device configuration (1)
Using endpoints 0x01 (out) and 0x81 (in)
Inquiring device details; driver will be detached ...
Looking for active driver ...
 No driver found. Either detached before or never attached

SCSI inquiry data (for identification)
-------------------------
  Vendor String: ZTE
   Model String: Mass storage
Revision String: 0000
-------------------------

USB description data (for identification)
-------------------------
Manufacturer: ZTE Incorporated
     Product: ZTE HSUSB Device
  Serial No.: CSE_P729V
-------------------------
Warning: no switching method given.
-> Run lsusb to note any changes. Bye.

In Windows, it seems to have some drivers what it wants to install.

O.K., thanks for the info.

I assume you can access the storage on Windows *without* installing the offered drivers, right?

Now what about the "adb" mode? Can you access the debug interface with the "adb.exe" tool from the Android SDK?
IIRC, the mode switch was a necessary step to reach this interface from Linux.

When the drivers *are* installed on Windows, can you access both storage and "adb" interface?

When I connect it to a Windows 7 machine, a fake CD-ROM drive appears with a driver on it.

When activating USB storage on the device, it will appear as a disk device in Window, without having to install any driver.

Before installing the driver on Windows, it is not possible to access the ADB.

After installing the driver on Windows, it is possible to access both storage and ADB, but not at the same time it seems.

BTW, I did not use the Windows driver on the device, I used one downloaded from www.zte.com.cn.

I think we are closing in now. If it is possible to recognize the storage mode (set on the device) and to tell it apart from the install mode, we could leave it alone and switch modes only if the latter is found.

You have already provided attribute data for the unswitched mode. I assume that is the mode when you see the pseudo CD-ROM.

Now we need the same data for the "real" storage mode in Linux, with all mode switching disabled. Can you provide that as well?

Is this what you want?

$ sudo usb_modeswitch -v 0x19d2 -p 0x1350

Looking for default devices ...
 Found devices in default mode, class or configuration (1)
Accessing device 006 on bus 001 ...
Getting the current device configuration ...
 OK, got current device configuration (1)
Using endpoints 0x01 (out) and 0x81 (in)
Not a storage device, skipping SCSI inquiry

USB description data (for identification)
-------------------------
Manufacturer: ZTE Incorporated
     Product: ZTE HSUSB Device
  Serial No.: CSE_P729V
-------------------------
Warning: no switching method given.
-> Run lsusb to note any changes. Bye.

Are you sure this is the storage mode which is set on the device? You should be able to access the storage from Linux as well ...

Maybe I was too short in my explanation. This phone has probably more than two different modes; so far, I assume there are three:

1. install mode: shows the pseudo CDROM and probably other storage drives
2. ADB/modem mode: activated by the Windows driver or by usb_modeswitch from mode 1
3. storage mode: shows only the phone storage drive(s)

These modes may be detectable either by a changed USB ID or by a changed internal setup (attributes, interfaces). It's quite possible that mode 1 and 2 appear as one setting on the device ("modem", "serial" or the like) and that only a mode switch will make it reach mode 2.

Of course, I may be totally wrong. To verify these assumptions, it will be necessary to check out the configuration of the modes in detail. This can be done with "sudo lsusb -v -d 19d2:<product_id>" for all possible settings, including the one that is reached when mode switching is activated again.

BTW, you don't need to edit the rules file to enable/disable the mode switch. Just edit /etc/usb_modeswitch.conf and set the DisableSwitching parameter.

Also, I found a hint that the product ID of the Blade has changed with the update to firmware 2.2, wrongly reusing the ID of the MF110 (which is the device targeted by the usb_modeswitch rule in question):
http://webcache.googleusercontent.com/search?q=cache:IihdR1Y7GQkJ:www.zte.com.au/ztebb2/viewtopic.php%3Ff%3D80%26t%3D768

(no direct access, thus a link to Google's cache)

So we definitely need a way to skip the Blade but keep the rule for the MF110.

> Are you sure this is the storage mode which is set on the device? You should be able to access the storage from Linux as well ...

Yes, I ran the command while accessing the storage.

> Also, I found a hint that the product ID of the Blade has changed with the update to firmware 2.2, wrongly reusing the ID of the
> MF110

This is likely the case, I have upgraded my device from 2.1 to 2.2.

Install mode

Bus 001 Device 005: ID 19d2:0083 ONDA Communication S.p.A. ZTE MF190
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 64
  idVendor 0x19d2 ONDA Communication S.p.A.
  idProduct 0x0083 ZTE MF190
  bcdDevice 2.26
  iManufacturer 1 ZTE Incorporated
  iProduct 2 ZTE HSUSB Device
  iSerial 3 CSE_P729V
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 32
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0x80
      (Bus Powered)
    MaxPower 500mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 2
      bInterfaceClass 8 Mass Storage
      bInterfaceSubClass 6 SCSI
      bInterfaceProtocol 80 Bulk (Zip)
      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 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
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)

Modem mode

Bus 001 Device 017: ID 19d2:1365 ONDA Communication S.p.A.
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 224 Wireless
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 64
  idVendor 0x19d2 ONDA Communication S.p.A.
  idProduct 0x1365
  bcdDevice 2.26
  iManufacturer 1 ZTE Incorporated
  iProduct 2 ZTE HSUSB Device
  iSerial 3 CSE_P729V
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 67
    bNumInterfaces 2
    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 224 Wireless
      bInterfaceSubClass 1 Radio Frequency
      bInterfaceProtocol 3 RNDIS
      iInterface 4 RNDIS Communications Control
      ** UNRECOGNIZED: 05 24 00 10 01
      ** UNRECOGNIZED: 05 24 01 00 01
      ** UNRECOGNIZED: 04 24 02 00
      ** UNRECOGNIZED: 05 24 06 00 01
      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 5 RNDIS Ethernet Data
      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
Device Qualifier (for other device speed):
  bLength 10
  bDescriptorType 6
  bcdUSB 2.00
  bDeviceClass 224 Wireless
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 64
  bNumConfigurations 1
Device Status: 0x0000
  (Bus Powered)

Storage/ADB mode

Bus 001 Device 012: ID 19d2:1350 ONDA Communication S.p.A.
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 64
  idVendor 0x19d2 ONDA Communication S.p.A.
  idProduct 0x1350
  bcdDevice 2.26
  iManufacturer 1 ZTE Incorporated
  iProduct 2 ZTE HSUSB Device
  iSerial 3 CSE_P729V
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 176
    bNumInterfaces 5
    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 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 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 1
      bAlternateSetting 0
      bNumEndpoints 3
      bInterfaceClass 255 Vendor Specific Class
      bInterfaceSubClass 0
      bInterfaceProtocol 0
      iInterface 0
      ** UNRECOGNIZED: 05 24 00 10 01
      ** UNRECOGNIZED: 05 24 01 00 00
      ** UNRECOGNIZED: 04 24 02 02
      ** UNRECOGNIZED: 05 24 06 00 00
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x83 EP 3 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x000a 1x 10 bytes
        bInterval 9
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x82 EP 2 IN
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
...

Excellent!

Now one last confirmation question:
Are you able to set both modem and storage/adb mode on the device? And - just out of interest - if that is the case, can you do so only with USB connection active or can you set it in advance before plugging in?

Anyway, two attributes are clearly different from the MF110/190 modems. One is "iSerial", the other is "iProduct". If we assume that the "iProduct" is more stable than the serial number, the solution to the Blade problem is to change the name of the respective config file from "19d2:0083" to "19d2:0083:uPr=WCDMA".

This will leave the Blade alone but still do the mode switch for the MF190.

Let me just state that I sincerely hope ZTE will stop reusing IDs for totally different devices.

No, it is not possible to use both modem and storage at the same time. Modem and storage can only be activated when the device is connected.

When I activate modem mode, the device switch Id from 1350 to 1365. Id 1350 also seems to be the default when neither storage or modem is activated.

ADB mode can be activated before plugging in, and it works in parallell with storage, but not in parallell with modem.

> Id 1350 also seems to be the default when neither storage or modem is
> activated.

Now I'm a little confused - I thought product ID 0x0083 is the default ??

So when is the install mode really active ? It has to come in at some point, or else you wouldn't have run into problems with usb_modeswitch ...

Yes, it's a bit strange.

With the current configuration, usb_modeswitch seems to do exactly the opposite of what it is supposed to do, it puts my device into install mode (0083). Without usb_modeswitch, my device ends up in non-install mode (1350) and things works fine. I uninstalled the usb-modeswitch and usb-modeswitch-data packages, and it works fine without them.

But when connecting my device to a Windows machine without driver, it ends up in install mode.

There seems to be quite a lot going on in the udev subsystem when you connect a USB device, can there be something else there which manages to take the ZTE Blade out of install mode (which usb_modeswitch then accidentally manage to undo)?

After running "sudo udevadm control --log-priority=debug", this is what I get in syslog when connecting the ZTE Blade (without usb-modeswitch installed):

Nov 27 11:32:50 localhost kernel: [ 434.700025] usb 1-5: new high speed USB device number 7 using ehci_hcd
Nov 27 11:32:50 localhost udevd[341]: seq 1821 queued, 'add' 'usb'
Nov 27 11:32:50 localhost udevd[341]: seq 1821 forked new worker [2122]
Nov 27 11:32:50 localhost udevd[2122]: seq 1821 running
Nov 27 11:32:50 localhost udevd[341]: seq 1822 queued, 'add' 'usb'
Nov 27 11:32:50 localhost udevd[2122]: device 0x22dc15b0 has devpath '/devices/pci0000:00/0000:00:04.1/usb1/1-5'
Nov 27 11:32:50 localhost udevd[2122]: no db file to read /run/udev/data/c189:6: No such file or directory
Nov 27 11:32:50 localhost udevd[341]: seq 1823 queued, 'add' 'scsi'
Nov 27 11:32:50 localhost udevd[341]: seq 1824 queued, 'add' 'scsi_host'
Nov 27 11:32:50 localhost udevd[2122]: PROGRAM 'mtp-probe /sys/devices/pci0000:00/0000:00:04.1/usb1/1-5 1 7' /lib/udev/rules.d/39-libmtp.rules:735
Nov 27 11:32:50 localhost udevd[2126]: starting 'mtp-probe /sys/devices/pci0000:00/0000:00:04.1/usb1/1-5 1 7'
Nov 27 11:32:50 localhost mtp-probe: checking bus 1, device 7: "/sys/devices/pci0000:00/0000:00:04.1/usb1/1-5"
Nov 27 11:32:50 localhost mtp-probe: bus: 1, device: 7 was not an MTP device
Nov 27 11:32:50 localhost udevd[2122]: 'mtp-probe /sys/devices/pci0000:00/0000:00:04.1/usb1/1-5 1 7'(out) '0'
Nov 27 11:32:50 localhost udevd[2122]: 'mtp-probe /sys/devices/pci0000:00/0000:00:04.1/usb1/1-5 1 7' [2126] exit with return code 0
Nov 27 11:32:50 localhost udevd[2122]: device 0x22dbccd8 has devpath '/devices/pci0000:00/0000:00:04.1/usb1'
Nov 27 11:32:50 localhost udevd[2122]: device 0x22dbce80 has devpath '/devices/pci0000:00/0000:00:04.1'
Nov 27 11:32:50 localhost udevd[2122]: device 0x22dbd048 has devpath '/devices/pci0000:00'
Nov 27 11:32:50 localhost udevd[2122]: IMPORT 'usb_id --export /devices/pci0000:00/0000:00:04.1/usb1/1-5' /lib/udev/rules.d/40-libgphoto2-2.rules:11
Nov 27 11:32:50 localhost udevd[2127]: starting 'usb_id --export /devices/pci0000:00/0000:00:04.1/usb1/1-5'
Nov 27 11:32:50 localhost kernel: [ 434.836568] scsi9 : usb-storage 1-5:1.0
Nov 27 11:32:50 localhost usb_id[2127]: custom logging function 0x2081b008 registered
Nov 27 11:32:50 localhost udevd[2122]: 'usb_id --export /devices/pci0000:00/0000:00:04.1/usb1/1-5'(out) 'ID_VENDOR=ZTE_Incorporated'
Nov 27 11:32:50 localhost udevd[2122]: 'usb_id --export /devices/pci0000:00/0000:00:04.1/usb1/1-5'(out) 'ID_VENDOR_ENC=ZTE\x20Incorporated'
Nov 27 11:32:50 localhost udevd[2122]: 'usb_id --export /devices/pci0000:00/0000:00:04.1/usb1/1-5'(out) 'ID_VENDOR_ID=19d2'
Nov 27 11:32:50 localhost udevd[2122]: 'usb_id --export /devices/pci0000:00/0000:00:04.1/usb1/1-5'(out) 'ID_MODEL=ZTE_HSUSB_Device'
Nov 27 11:32:50 localhost udevd[2122]: 'usb_id --export /devices/pci0000:00/0000:00:04.1/usb1/1-5'(out) 'ID_MODEL_ENC=ZTE\x20HSUSB\x20Device'
Nov 27 11:32:50 localhost udevd[2122]: 'usb_id --export /devices/pci0000:00/0000:00:04.1/usb1/1-5'(out) 'ID_MODEL_ID=0083'
Nov 27 11:32:50 localhost udevd[2122]: 'usb_id --export /devices/pci0000:00/0000:00:04.1/usb1/1-5'(out) 'ID_R...

I think I'm beginning to see the 'logic'. It might have been sufficient to look at the "dmesg" output, though. It might even give you the USB ID of new devices.

A second after plugging the device does autoswitch its mode. Look for:

[ 434.700025] usb 1-5: new high speed USB device number 7
...
[ 435.839094] usb 1-5: USB disconnect, device number 7
...
[ 436.280028] usb 1-5: new high speed USB device number 8

I strongly suspect that usb_modeswitch interferes with the process and prevents the switch.
Yet it is not clear why there is an autoswitch in Linux only and not in Windows. Maybe some driver action (or non-action) triggers that. It would be interesting to see what kind of effect a blacklisting of usb-storage might have.

Anyway, as I said, if the match string "uPr=WCDMA" is appended to the name of the config file, there will be no more interaction with the Blade. For this, extract all files from "/usr/share/usb_modeswitch/configPack.tar.gz" to the same folder and rename "19d2:0083" to "19d2:0083:uPr=WCDMA". At your liking you can repack the files - or not.

Renaming to 19d2:0083:uPr=WCDMA and repacking /usr/share/usb_modeswitch/configPack.tar.gz seems to work.

Very good. I will change this in the next upstream release of the data package.

Hi, I have a ZTE-C N600 CDMA2000 mobile phone. It runs on a linux 2.6.29 kernel and android 2.1-update1 OS. I met exactly the same situation on my Ubuntu 11.10.

When I plug my phone on my computer and after cold boot my computer, lsusb got:

Bus 001 Device 002: ID 19d2:1350 ONDA Communication S.p.A.

in this status, I can run adb tool to access my phone. If I unplug my phone and re-plug it, lsusb got:

Bus 001 Device 004: ID 19d2:0083 ONDA Communication S.p.A. ZTE MF190

then, adb can not find my phone. and syslog got:

Dec 11 13:39:13 dongjia kernel: [ 4199.313844] usb 1-5: USB disconnect, device number 6
Dec 11 13:39:17 dongjia kernel: [ 4203.804035] usb 1-5: new high speed USB device number 7 using ehci_hcd
Dec 11 13:39:17 dongjia kernel: [ 4203.939708] scsi6 : usb-storage 1-5:1.0
Dec 11 13:39:17 dongjia mtp-probe: checking bus 1, device 7: "/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-5"
Dec 11 13:39:17 dongjia mtp-probe: bus: 1, device: 7 was not an MTP device
Dec 11 13:39:18 dongjia usb_modeswitch: switching 19d2:0083 (ZTE Incorporated: ZTE HSUSB Device)

I know it is related with usb_modeswitch, but I don't understand what should I do. You guys mentioned "Renaming to 19d2:0083:uPr=WCDMA and repacking /usr/share/usb_modeswitch/configPack.tar.gz", is it means rename the file-name "19d2:0083" to "19d2:0083:uPr=WCDMA" inside "/usr/share/usb_modeswitch/configPack.tar.gz"? I can't find any individual file named "19d2:0083", neither in "/etc" nor "/etc/usb_modeswitch.d".

Thanks for your help, and if you need any testing or hardware information, please just let me know (the exactly commands. ;-) ). Thank you.

Hi, some additional information, I found this command is useful on my ZTE-C 600 mobile phone:
usb_modeswitch -W -s 20 -v 0x19d2 -p 0x0083 -V 0x19d2 -P 0x1350 -m 0x01 -M "55534243f8f993882000000080000a85010101180101010101000000000000"

after that, although last message reports "Mode switch has failed. Bye.", but the id has changes to:
Bus 001 Device 015: ID 19d2:1366 ONDA Communication S.p.A.

and related syslog here:

---- unplug ZTE-C 600
--------------------------------
Dec 11 14:37:34 dongjia kernel: [ 7701.097180] usb 1-5: USB disconnect, device number 13
Dec 11 14:37:34 dongjia kernel: [ 7701.116288] scsi: killing requests for dead queue

---- replug ZTE-C 600
--------------------------------
Dec 11 14:37:44 dongjia kernel: [ 7710.988033] usb 1-5: new high speed USB device number 14 using ehci_hcd
Dec 11 14:37:44 dongjia kernel: [ 7711.123641] scsi13 : usb-storage 1-5:1.0
Dec 11 14:37:44 dongjia mtp-probe: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-5"
Dec 11 14:37:44 dongjia mtp-probe: bus: 1, device: 14 was not an MTP device
Dec 11 14:37:45 dongjia usb_modeswitch: switching 19d2:0083 (ZTE Incorporated: ZTE HSUSB Device)

---- manually run usb_modeswitch
--------------------------------
Dec 11 14:37:57 dongjia kernel: [ 7723.853210] usb 1-5: usbfs: process 5865 (usb_modeswitch) did not claim interface 0 before use
Dec 11 14:37:57 dongjia kernel: [ 7723.949317] usb 1-5: USB disconnect, device number 14
Dec 11 14:37:58 dongjia kernel: [ 7724.700036] usb 1-5: new high speed USB device number 15 using ehci_hcd
Dec 11 14:37:58 dongjia mtp-probe: checking bus 1, device 15: "/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-5"
Dec 11 14:37:58 dongjia kernel: [ 7724.836545] scsi14 : usb-storage 1-5:1.3
Dec 11 14:37:58 dongjia mtp-probe: bus: 1, device: 15 was not an MTP device
Dec 11 14:37:59 dongjia kernel: [ 7725.837074] scsi 14:0:0:0: Direct-Access ZTE Mass Storage ffff PQ: 0 ANSI: 2
Dec 11 14:37:59 dongjia kernel: [ 7725.837668] scsi scan: INQUIRY result too short (5), using 36
Dec 11 14:37:59 dongjia kernel: [ 7725.837676] scsi: killing requests for dead queue
Dec 11 14:37:59 dongjia kernel: [ 7725.856147] scsi: killing requests for dead queue
Dec 11 14:37:59 dongjia kernel: [ 7725.874561] scsi: killing requests for dead queue
Dec 11 14:37:59 dongjia kernel: [ 7725.874698] scsi: killing requests for dead queue
Dec 11 14:37:59 dongjia kernel: [ 7725.878666] scsi: killing requests for dead queue
Dec 11 14:37:59 dongjia kernel: [ 7725.878802] scsi: killing requests for dead queue
Dec 11 14:37:59 dongjia kernel: [ 7725.884164] scsi: killing requests for dead queue
Dec 11 14:37:59 dongjia kernel: [ 7725.884301] scsi: killing requests for dead queue
Dec 11 14:37:59 dongjia kernel: [ 7725.888743] sd 14:0:0:0: Attached scsi generic sg2 type 0
Dec 11 14:37:59 dongjia kernel: [ 7725.896206] sd 14:0:0:0: [sdb] Attached SCSI removable disk

Yes, it is about renaming the file inside the /usr/share/usb_modeswitch/configPack.tar.gz archive.

AFAIK, that's fixed in the upstream 20120120 release.

I'm deeply sorry to say I did not remember to apply the fix ...

Data package 20120529 has just been released - I am going to make the change immediately and release 20120531.
Didier, I hope you did not repackage the new release yet ...

O.K., I released 20120531 with the fix applied.

Sorry again for the lapse of memory.