USB_ModeSwitch

Ok, I've found anohter modem to play with, this one is used mainly in Taiwan so I can't find any sites in english :( Translated pages are, like, crazy ;)

It has the codes Vendor=0x0408 ProdID=0x1000 before switching, and when looking in windows it seems it switches to Vendor=0x0408 ProdID=0xEA02.

I've sniffed the 0x1000 device until it dissapears, so I should have the switch command in there... I have a couple of traces and they're identical except from some addresses, probably dynamically assigned.

I haven't managed to switch it, I hoped you guys could help me find the switch command.

There is no message containing "00 00 06 01" or similar, the only "00 00 06 "-something is "00 00 06 00", two of them (see below) but they don't seem to work. :(

Two enpoints are used, 0x05 and 0x84, according to this:

[63 ms] <<< URB 8 coming back <<<
-- URB_FUNCTION_SELECT_CONFIGURATION:
ConfigurationDescriptor = 0x8205b0b8 (configure)
ConfigurationDescriptor : bLength = 9
ConfigurationDescriptor : bDescriptorType = 0x00000002
ConfigurationDescriptor : wTotalLength = 0x00000020
ConfigurationDescriptor : bNumInterfaces = 0x00000001
ConfigurationDescriptor : bConfigurationValue = 0x00000001
ConfigurationDescriptor : iConfiguration = 0x00000000
ConfigurationDescriptor : bmAttributes = 0x00000080
ConfigurationDescriptor : MaxPower = 0x00000032
ConfigurationHandle = 0x821a5aa0
Interface[0]: Length = 56
Interface[0]: InterfaceNumber = 0
Interface[0]: AlternateSetting = 0
Interface[0]: Class = 0x00000008
Interface[0]: SubClass = 0x00000006
Interface[0]: Protocol = 0x00000050
Interface[0]: InterfaceHandle = 0xf7d78768
Interface[0]: NumberOfPipes = 2
Interface[0]: Pipes[0] : MaximumPacketSize = 0x00000040
Interface[0]: Pipes[0] : EndpointAddress = 0x00000084
Interface[0]: Pipes[0] : Interval = 0x00000000
Interface[0]: Pipes[0] : PipeType = 0x00000002 (UsbdPipeTypeBulk)
Interface[0]: Pipes[0] : PipeHandle = 0xf7d78784
Interface[0]: Pipes[0] : MaxTransferSize = 0x00001000
Interface[0]: Pipes[0] : PipeFlags = 0x00000000
Interface[0]: Pipes[1] : MaximumPacketSize = 0x00000040
Interface[0]: Pipes[1] : EndpointAddress = 0x00000005
Interface[0]: Pipes[1] : Interval = 0x00000000
Interface[0]: Pipes[1] : PipeType = 0x00000002 (UsbdPipeTypeBulk)
Interface[0]: Pipes[1] : PipeHandle = 0xf7d787a4
Interface[0]: Pipes[1] : MaxTransferSize = 0x00001000
Interface[0]: Pipes[1] : PipeFlags = 0x00000000

First 05 message:
[89 ms] >>> URB 11 going down >>>
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
PipeHandle = 82214fdc [endpoint 0x00000005]
TransferFlags = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 0000001f
TransferBuffer = 8243fbc8
TransferBufferMDL = 00000000
00000000: 55 53 42 43 38 47 4f fc 24 00 00 00 80 00 06 12
00000010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00
UrbLink = 00000000

equals(?):
usb_modeswitch -v 0x0408 -p 0x1000 -m 0x05 -M 5553424338474ffc2400000080000612000000240000000000000000000000
- nothing happens


last 05 message with a look-a-like message
[8720 ms] >>> URB 376 going down >>>
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
PipeHandle = 82214fdc [endpoint 0x00000005]
TransferFlags = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 0000001f
TransferBuffer = 8243fbc8
TransferBufferMDL = 00000000
00000000: 55 53 42 43 38 47 4f fc 00 02 00 00 00 00 0a 2a
00000010: 00 00 00 00 33 00 00 01 00 00 00 00 00 00 00
UrbLink = 00000000

equals:
usb_modeswitch -v 0x0408 -p 0x1000 -m 0x05 5553424338474ffc0002000000000a2a000000003300000100000000000000
- does nothing

first 05 message with a "00* 06" entry
[7477 ms] >>> URB 195 going down >>>
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
PipeHandle = 82214fdc [endpoint 0x00000005]
TransferFlags = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 0000001f
TransferBuffer = 8243fbc8
TransferBufferMDL = 00000000
00000000: 55 53 42 43 30 c8 3e f8 00 00 00 00 00 00 06 00
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
UrbLink = 00000000

equals:
usb_modeswitch -v 0x0408 -p 0x1000 -m 0x05 5553424330c83ef80000000000000600000000000000000000000000000000
- nothing

Second (and last) message with a "00* 06" entry
[7488 ms] >>> URB 200 going down >>>
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
PipeHandle = 82214fdc [endpoint 0x00000005]
TransferFlags = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 0000001f
TransferBuffer = 8243fbc8
TransferBufferMDL = 00000000
00000000: 55 53 42 43 30 18 09 f8 00 00 00 00 00 00 06 00
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
UrbLink = 00000000

equals:
usb_modeswitch -v 0x0408 -p 0x1000 -m 0x05 55534243301809f80000000000000600000000000000000000000000000000
- nothing


After the last message with similar data to 05 there are some more messages without data plus one with a large block of data. It ends with two messages to 84, with a little data:
[8724 ms] >>> URB 378 going down >>>
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
PipeHandle = 82214fbc [endpoint 0x00000084]
TransferFlags = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 0000000d
TransferBuffer = 8243fbc8
TransferBufferMDL = 00000000
00000000: 55 53 42 43 38 47 4f fc 00 02 00 00 00
UrbLink = 00000000
[8726 ms] UsbSnoop - MyInternalIOCTLCompletion(f78f0db0) : fido=820276d8, Irp=fc4f4738, Context=f7fce740, IRQL=2
[8726 ms] <<< URB 378 coming back <<<
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
PipeHandle = 82214fbc [endpoint 0x00000084]
TransferFlags = 00000001 (USBD_TRANSFER_DIRECTION_IN, ~USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 0000000d
TransferBuffer = 8243fbc8
TransferBufferMDL = 820419e8
00000000: 55 53 42 53 38 47 4f fc 00 00 00 00 00
UrbLink = 00000000


Any ideas?

Please stand by, I'm on vacation right now and rarely online.

I'll try to respond properly on Monday.

OK, Monday was a lie ...

I too find the "00 60" command is the most suspicious. This command (SCSI: TEST UNIT READY) is also used by ZTE/ONDA modems.

Just for fun try with a different tag sequence (Byte 4-7); the tag is freely selectable. Like this:

55 53 42 43 12 34 56 78 00 00 ...

For pasting:

55534243123456780000000000000600000000000000000000000000000000

THEORETICALLY, there should be no difference, but who knows ...

Do you have some sort of SCSI command reference? Is it downloadable from somewhere?

Sorry for the delay, I've been on vacation - again ...

Here is the link where I got mine:
http://www.usb.org/developers/devclass_docs/usbmass-ufi10.pdf

For USB mass storage the SCSI interface was adopted. Don't ask me how far the resemblance goes.

Hi, I'm working on the same project as joke_dst (actually covering for him while he's on vacation!).

I've managed to switch the modem, however it won't switch until I reboot linux. So I'm guessing I need to figure out one more command to make it dismount and remount itself as the modem. I guess the system sends such commands to it while rebooting..

Anyway, here's the command I send to the modem prior to rebooting and having it switch:
After reboot it will show up as device 0xea02, unfortunately, I have not found any tty ports on it yet.

Edit:

I've connected it to a couple of windows machines to try sniffing some more. On both machines, the device switched (without having drivers installed) when I had it replugged through the sniffer programs. (I.e., disconnecting and reconnecting the device WITHOUT unplugging it physically from the usb port.)

I guess this is what also happens in linux when I reboot the device and the modem switches on its own. Now, what I need to figure out is how to replug usb devices in the same manner, without having to reboot.

I'd be really thankful for any advice on this. I've spent about 4-5 hours on google today trying to find out how to replug or just disable/enable the usb port in linux, with no luck what so ever.

I just released version 0.9.4. For your case I inserted some more lines into the code which you can comment out and try. Look for "usb_reset". No guarantees, but tell me what happens.

If it works, I have to implement it more cleanly, probably as a new option.

BTW, a nice tool to see what happens is "udevmonitor". Call it in a console, plug the device in and try to switch in a different console. On my system I could see the switch happen and udev not "letting go".

Thanks Josh, that usb_reset did the trick! Sending a single command is not enough however, it will reset and switch after receiving about 5-15 consequent commands (like the one in my previous post).

I have not been able to determine when it will/won't reset, but it seems to do it for sure if I send up to 15 commands. I will keep testing to see if I can learn more. So far however, it's a great step forward.

It would be great if you could implement the usb_reset() as an option. There are rare cases where modems seem to freeze up (they stop working and lights flashing randomly). The usb_reset function might be a way to solve such problems, not only to switch stubborn modems!

We finally got this modem to connect! All we have to do is to send AT+CFUN=1 to one of the tty's (this modem has three that listens to at commands, on our device it's ttyUSB2)).

I use MU-Q101 with linux (kernel: 2.6.22.10)

usb 2-2: new full speed USB device using ohci_hcd and address 17
usb 2-2: device descriptor read/64, error -62
usb 2-2: device descriptor read/64, error -62
usb 2-2: new full speed USB device using ohci_hcd and address 18
usb 2-2: device descriptor read/64, error -62
usb 2-2: device descriptor read/64, error -62
usb 2-2: new full speed USB device using ohci_hcd and address 19
usb 2-2: device not accepting address 19, error -62
usb 2-2: new full speed USB device using ohci_hcd and address 20
usb 2-2: device not accepting address 20, error -62
usb 2-2: new full speed USB device using ohci_hcd and address 21
usb 2-2: new full speed USB device using ohci_hcd and address 22
usb 2-2: configuration #1 chosen from 1 choice
scsi2 : SCSI emulation for USB Mass Storage devices
the ID = 0,<7>usb-storage: device found at 22
scsi 2:0:0:0: Direct-Access Qualcomm MMC Storage 2.31 PQ: 0 ANSI: 2

Then I use usb_modeswitch and put this command

# usb_modeswitch -v 0x0408 -p 0x1000 -m 0x05 -M 5553424338474ffc0002000000000a2a
000000003300000100000000000000

The console show :
* usb_modeswitch: tool for controlling "flip flop" mode USB devices
* Version 0.9.4 (C) Josua Dietze 2008
* Works with libusb 0.1.12 and probably other versions

Looking for default devices
Found default devices (1)
Prepare switching, accessing latest device
Looking for active default driver to detach it
OK, driver found ("usb-storage")
OK, Driver "usb-storage" successfully detached
Setting up communication with device
Trying to send the message
OK, message successfully sent.
usb 2-2: reset full speed USB device using ohci_hcd and address 16
-> See /proc/bus/usb/devices (or call lsusb) for changes. Bye

But I can't see correct modem's vid=0x0408 and pid=0xea02

Please help me to solve this problem.

Hi,

just want to let you know that I have a MU-Q101 and tried the usb-modeswitch tool successfully. However, the kernel does not recognize that the device has changed the product ID from 0x1000 to 0xea02 and therefor simply reloading the uhci-hcd module does not do the trick. Instead, find the device address where the device is registered on the usb bus and send a 'suspend' to it. It will wake up again after a few seconds and carry the correct product id. Then a modprobe usbserial with the correct vendor and product IDs submitted will create the ttyUSB devices.

Example: if the device is connected to usb 1-2 according to dmesg, then the command would be:
echo suspend > /sys/bus/usb/devices/1-2/power/level (as root of course)

It would be great to get the whole thing integrated natively into udev, don't you think?

O.K., the last two posts - are you able to recompile the tool (0.9.4)?

If so, you might try the same trick as joke_dst: there is an out-commented line in the source file; look for "usb_reset". Remove the comment characters and re-compile.

This is a really heavy weapon against the system. Right, udev would be the point for integration; as it is now, we are really working against it ...
The devices DO switch, but the changes are sometimes not accepted by the host system.

Tell me if you can't compile - I'll post a binary then.

the usb_reset doesn't do the trick for me. I tried this already. My system is Ubuntu Hardy Heron with kernel 2.6.24-19. So, it may be the kernel version...?

Thanks both Josh and mixmaxtw !!!
In my system, there is nothing in /sys/bus/usb/devices/1-2/, so I try to find out the folder and file.
When I can echo "suspend" to /sys/bus/usb/devices/1-2/power/level , the magic thing happened !!
The way "echo suspend > /sys/bus/usb/devices/1-2/power/level " , and the other way "usb_modeswitch -v 0x0408 -p 0x1000 -m 0x05 -M 5553424338474ffc0002000000000a2a
000000003300000100000000000000" both can "suspend" the mass stroage , then wake up the correct modem.
Finally , I can use QU101 to connect internet ...

@sfe:

How did you get it to connect to the internet? Somehow I cannot get ppp to work... can you share your configuration with me?

I can issue AT commands via minicom and receive OKs... and after a AT+CFUN=1 or the AT+CGDCONT=1,"IP","internet","",0,0 plus ATD*99# combination the light on the HSDPA modem is blinking blue, suggesting a successful connect. However no CONNECT reply is given, so ppp fails...

Any hints welcome.