[Solved] ZTE MF626 switching issue

jpc · Post by **jpc** » 10 Jul 2012, 12:25

Hi,

I have a ZTE MF626 key that has stopped switching properly since using the last usbmodeswitch data file (20120531)
This key id is 19d2:2000 and its target id is 19d2:0031.
When plugging the key, it is switching properly and tty are appearing but they disappear instantaneously.

After investigating, I noticed that a new file has been recently added :

Code: Select all

root@OpenWrt:/# cat /etc/usb_modeswitch.d/19d2\:0031 
# ZTE MF637

TargetVendor=  0x19d2
TargetProduct= 0x0094

MessageContent="5553424312345678000000000000061b000000020000000000000000000000"
NeedResponse=1

And I think this is the cause of my troubles since as soon as the key has switched and its id have changed, usb_modeswitch is called again using the file above and this cause the ttys to disappear.

Could anybody confirm that this file (19d2:0031) is correct ?

Regards.

jpc · Post by **jpc** » 10 Jul 2012, 13:28

It seems that other ID have the same "issue" i.e. a usb ID is both a target and a source, but ZTE MF626 is the only case where the second target id (i.e. the one when initial target id is used as a source id) is different.

I'm not sure but it is possible that IDs that have this issue but using targetClass might not have any trouble ?

The following table lists the IDs that might exhibit this behaviour :

| Source ID | Target ID - Source ID 2 | Target ID 2 |
| 0af0:d001 | 0af0:d157 | 0af0:d157 (targetClass) |
| 12d1:1553 | 12d1:1001 | 12d1:1001 (targetClass) |
| 12d1:1446 | 12d1:1001 | 12d1:1001 (targetClass) |
| 19d2:0053 | 19d2:0031 | 19d2:0094 |
| 19d2:0103 | 19d2:0031 | 19d2:0094 |
| 19d2:2000 | 19d2:0031 | 19d2:0094 |
| 1033:0035 | 12d1: 1003 | 12d1:1003 (targetClass) |
| 1c9e:1001 | 1c9e:6061 | 1c9e:6061 (targetClass)|

Regards.

Post by **Josh** » 10 Jul 2012, 23:01

Can you try the following edit?

In /lib/udev/rules.d/40-usb_modeswitch.rules there is a line matching the interface number (line 19 or so).

Now change

ATTRS{bInterfaceNumber}!="0[059]"

to

ATTRS{bInterfaceNumber}!="0[09]"

Does that make a difference?

jpc · Post by **jpc** » 10 Jul 2012, 23:24

Hi,

Thanks for the quick answer.
Unfortunately I'm using openwrt with hot plug scripts...

Is there anything I can do to have the same modification as the suggested one in a script ?

Can you confirm that this file is not bogus ? I tried to search on the net for those ids for the mf637 dongle but could not find anything usefully.

Regards.

Post by **Josh** » 11 Jul 2012, 19:38

The configuration is not bogus, it's in the device reference and I remember scratching my head over it because of that ambiguity.

In the end, I assumed the "filter" in the udev rule would be sufficient to prevent a conflict. What it basically does is:
Only accept interface 0,5,9 and only if the interface class is "8". There could be a conflict if your modem happens to have a storage interface on 5 after mode-switching.

I'm afraid you have to ask somewhere else about the hotplug method of your system. There must be a way to detect certain USB IDs, so maybe the class of interface 0 is also detectable.

After some thinking I'm also pondering about a new safety switch in the usb_modeswitch binary which denies switching if no class "8" is found, to be overridden with a command line flag.

jpc · Post by **jpc** » 12 Jul 2012, 10:41

Hi,

I've modified openwrt hotplug script so that it has the same behaviour as the provided Udev rules file i.e. :
* No switching if USB Interface number is not 00, 05 or 09
* No switching if USB device class is not 08 and USB Interface class is not 03 or 08

My MF626 dongle is working fine again.

Thanks for your help.

Regards.

[Solved] ZTE MF626 switching issue

[solved] ZTE MF626 switching issue