[cooper]

Hi,

I'm working on integrating usb_modeswitch into a set of udev rules, so the devices will be automatically switched upon connection.

This works fine so far, but there is a problem with devices with initially the same idVendor/idProduct which seems to require different handling after switching to modem mode.

For example, the Option devices in the usb_modeswitch.conf.

For the ZeroCD feature, all use the same idVendor/idProduct, 05c6/1000, and all use the same MessageEndpoiont and MessageContent. After mode switch, they appear as 05c6/6901, 05c6/6600 and 05c6/6701. And some of them seems to need a response reading.

When it comes to integrating it into udev, it seems to me that we have two different jobs to do which are currently hooked together:
1) switch a device 05c6/1000 using MessageEndpoint X and MessageContent Y
2) Look for a device 05c6/6600 or 05c6/6701, read from Endpoint Z

There are some questions arising of this.

For a first "workaround", is there anything bad in reading from Endpoint Z regardless which of the three option devices is connected? Then the config rule for device 05c6/6600 should work for the other two devices as well (given we change the IDs appropriately). Could anyone with appropriate hardware confirm/try out this?

For a real solution, couldn't we just seperate the two jobs into two different calls of usb_modeswitch? The implementation would be a rule calling usb_modeswitch without ResponseEndpoint whenever a device 05c6/1000 connects, and two more rules calling usb_modeswitch to read from Endpoint Z whenever a device 05c6/6600 or 05c6/6701 connects.

And, is anybody out there having an Option Option GlobeTrotter GT MAX 3.6 or T-Mobile Web'n'walk Card Compact II (05c6/6600) who could test if it's working?

Thanks, dc

[Josh]

This works fine so far, but there is a problem with devices with initially the same idVendor/idProduct which seems to require different handling after switching to modem mode.

This is why fully automated handling (e.g. integrated in distributions) is pretty hard to do.

After mode switch, they appear as 05c6/6901, 05c6/6600 and 05c6/6701. And some of them seems to need a response reading.

You probably ran into a misunderstanding here: the devices known so far needing to read the response, do so on the old device. They wait for the response to the bulk transfer with the switch command; this is happening in communication with the endpoints of the original device.

The switching is as radical as a re-plug of the device. New devices appear with completely different endpoints, so there is no point in getting a response to an earlier command to a device that is not there anymore.

Now, concerning your extension to configure the system bus address, this is valuable in any case; using the bus parameters in the udev rule we could guarantee that exactly the device which was just plugged is addressed by USB_ModeSwitch!

The procedure implemented now is just to look for the last unswitched device; it's technically possible to plug two identical devices at the same time and get a collision of two instances of USB_ModeSwitch trying to connect with the same device.

Also, for future implementation of a success check, it's essential to note the "address" of a device on the bus.

[cooper]

You're right, I misunderstood the ResponseEndpoint thing.

I wonder how the Windows driver is able to distinguish between the various devices and chooses the right switching method, if all appear with the same idVendor/idProduct.

Maybe a closer inspection of the /sysfs files of these devices could lead to some new insights, pitty that I have none of them.

So I fear a workaround is all we can use at the moment.

What about this:

All the Option devices, as I fas as I could see from the config file, use the same MessageEndpoint and the same MessageContent for mode switching. But two of them will switch only after reading from the ResponseEndpoint -- which is the same for both devices. And all four will change their idProduct.

So we could fire always the same MessageContent to these four devices, regardless of the model, and then wait some milliseconds. Is the device still there, it did not switch -- so we read from the ResponseEndpoint. Success wound be if the device disconnected after the switching command, either without reading from the ResponseEndpoint or after reading.

The ONDA MT503HS ist a real problem, it looks entirely like the ZTE MF628 but needs a different MessageContent. It's the same with the ZTE MF622 and MF620, both same idVendor/idProduct and MessageEndpoint, but differend MessageContents.

Luckily, all four change their idProduct on mode switching, so they disconnect and reconnect. A workaround could be to send the first mode switch command, wait some milliseconds if the device vanishes, and if not try the next MessageContent, till it's gone.

The only thing I don't know is if does any harm to these devices if you send them the wrong MessageCommand, or if you could really keep trying till you send the right command.

It could help a lot knowing some people owning these four ZTE/ONDA devices. Maybe they could contribute some /sysfs informations, perhaps we could find a difference somewhere we could rely on.

But till then, how about testing this workaround? Any comments?