Thank you, Josh!

Hi! commit 6ba592574d59bf9ab3aa890f536b00acc60b9095 Author: Alexander Gordeev <lasaine@lvk.cs.msu.su> Date: Wed Aug 31 12:01:04 2011 +0400 use the first available interface instead of zero In some broken devices interface numbers start from 1 while in other devices with the same VID:PID combination ...

I've tested it on several machines, works ok with the patch!

I've often seen configuration switching failed due to kernel driver was attached. You can see it in dmesg: usb 1-1: usbfs: interface 0 claimed by usb-storage while 'usb_modeswitch' sets config #1 While we can simply detach kernel driver right before switching configuration this potentially can be a ...

Hmm, maybe it was too fast: the switching is quite unstable. I'll have to debug further.

Hi! I have successfully switched to the modem mode using this addition to udev rules: # Huawei EchoLife BM325 WiMAX USB Modem ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="3808", RUN+="usb_modeswitch '%b/%k'" and this config file: #########################################...

Its class is indeed 0xff, but I'm quite sure that it isn't a usb-serial device. There is no working driver for it yet, but I know the protocol partially.

Sent it.

BTW, I noticed that after the switch an 'option' driver is binded to the device. And it seems that usb_modeswitch did it. However I'm quite sure that it should not be handled by an 'option' driver. Can I stop this somehow?

Hi! I have successfully switched to the modem mode using this addition to udev rules: # Beceem BCSM250 ATTRS{idVendor}=="198f", ATTRS{idProduct}=="bccd", RUN+="/usr/share/usb_modeswitch/usb_modeswitch.sh '%b/%k'" and this config file: ###################################...