[morgwai]

Hi,

I've got GT Max 7.2 ready (serial number starting with FT, GX0201 model) with Zero-CD so I tried to use usb_modeswitch - my /etc/usb_modeswitch.conf looks like this:

Code: Select all

########################################################
# Option GlobeTrotter GT MAX "7.2 Ready"
#
# Timing is an issue here when automated with udev. See homepage!
#
# Contributor: Lucas Benedicic

DefaultVendor=          0x05c6
DefaultProduct= 0x1000

TargetVendor=           0x0af0
TargetProduct=          0x6701

MessageEndpoint=0x05
MessageContent="5553424308e0f8840800000080000a4a010000000000000800000000000000"

but after calling usb_modeswitch nothing really changes:

Code: Select all

morgwai@darkstorm:~$ lsusb
Bus 006 Device 001: ID 0000:0000
Bus 007 Device 002: ID 05c6:1000 Qualcomm, Inc.
Bus 007 Device 001: ID 0000:0000
Bus 005 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
morgwai@darkstorm:~$ sudo usb_modeswitch

 * usb_modeswitch: tool for controlling "flip flop" mode USB devices
 * Version 0.9.2 (C) Josua Dietze 2007
 * Works with libusb 0.1.12 and probably other versions

Looking for target device
 OK, target device not found. Action required
Looking for default device
 Ok, found default device. Prepare switching
Looking for active default driver to detach it
 OK, driver found ("usb-storage")
 OK, Driver "usb-storage" successfully detached
Trying to send the message
 OK, message successfully sent.
-> See /proc/bus/usb/devices (or call lsusb) for changes. Bye

morgwai@darkstorm:~$ lsusb
Bus 006 Device 001: ID 0000:0000
Bus 007 Device 002: ID 05c6:1000 Qualcomm, Inc.
Bus 007 Device 001: ID 0000:0000
Bus 005 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

I thought that maybe my card is one of those that don't change id after switching, but when I try to load nozomi drivers nothing happens (output from `cat /proc/devices |grep 241` is empty and when I try to establish connection with pppd I receive ''No such device or address" error message)
Any suggestions?

Thanks

Morg

[Josh]

...
but after calling usb_modeswitch nothing really changes

The "Option" devices that I know do always change the IDs cleanly.

But your device is one of those which might need a delay of 3-4 seconds before the run of USB_ModeSwitch. Should work with a manual call though (I can't confirm that, but Lucas Benedicic should know, I'll ask him to join the forum).

For the delayed execution see the USB_ModeSwitch page.

If nothing helps, I suspect the message string might be uncorrect. If you want to be 100% sure there is no other way than to do the Windows sniffing ...

[morgwai]

But your device is one of those which might need a delay of 3-4 seconds before the run of USB_ModeSwitch. Should work with a manual call though (I can't confirm that, but Lucas Benedicic should know, I'll ask him to join the forum).

Well, I called usb_modeswitch several minutes after plugging the card in - if you could ask Lucas to give me some advice what to check I'd be grateful.

If nothing helps, I suspect the message string might be uncorrect. If you want to be 100% sure there is no other way than to do the Windows sniffing ...

That's what I will probably do as soon as I get to some windows notebook (most of my colleagues have linux laptops or macs...)

Thanks for your help!

Morg

[Danni]

I've found that my card (same as yours for being the 7.2 ready, FT start- can't check the number while using it) requires me to use usb_modeswitch within a few seconds of plugging it in, otherwise it doesn't work and stays as Qualcomm. Delaying actually makes it worse.

[Josh]

Delaying actually makes it worse.

If that proves to be the solution I'll wait for confirmation and then I'm going to update the docs. Maybe I did not understand Lucas to the full extent; I thought that just a minimum delay was relevant.

He found for his setup a delay of 4 and for the setup of a friend a delay of 3 seconds most reliable.

[morgwai]

Ok, I've tried all delays between 1 and 10 seconds but it never worked so far

I got access to some windows notebook and sniffed the traffic to check whether the control sequence in the config file is valid for my card - it's a 60kb file - what should I look for?

Thanks

Morg

[Josh]

what should I look for?

If you used "SniffUSB" on the storage device see the last transactions before the device vanishes ("IRP_MN_SURPRISE_REMOVAL").

The logs are pretty verbose because every transaction is listed with all confirmation and response stuff written out.
Look for the last URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER that is "going down" with a hex "message" like this:

Code: Select all

...
TransferBufferMDL    = 00000000
  00000000: 55 53 42 43 08 20 d8 86 00 00 00 00 00 00 06 01
  00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
UrbLink              = 00000000
...

(By the way, that is the message sequence for my Icon.)

If the sequence you found still doesn't work try others with a similar length that occur before the last one, working backwards from the end of the log.

[morgwai]

ok so the last message before "surprise removal" is here (URB 52):

Code: Select all

[215 ms]  >>>  URB 51 going down  >>> 
-- URB_FUNCTION_RESET_PIPE:
  PipeHandle = 855ec8f4 [endpoint 0x00000084]
[216 ms] UsbSnoop - MyInternalIOCTLCompletion(f7991db0) : fido=00000000, Irp=85488658, Context=86e2ba68, IRQL=0
[216 ms]  <<<  URB 51 coming back  <<< 
-- URB_FUNCTION_RESET_PIPE:
[216 ms] UsbSnoop - DispatchAny(f7990610) : IRP_MJ_INTERNAL_DEVICE_CONTROL
[216 ms] UsbSnoop - MyDispatchInternalIOCTL(f7991e80) : fdo=85adb2e0, Irp=85429008, IRQL=0
[216 ms]  >>>  URB 52 going down  >>> 
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
  PipeHandle           = 855ec8f4 [endpoint 0x00000084]
  TransferFlags        = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 0000000d
  TransferBuffer       = 852c6b18
  TransferBufferMDL    = 00000000
    00000000: 55 53 42 43 08 90 42 85 00 00 00 00 00
  UrbLink              = 00000000
[385 ms] UsbSnoop - DispatchAny(f7990610) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
[385 ms] UsbSnoop - MyDispatchPNP(f7992ee0) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
[385 ms] UsbSnoop - DispatchAny(f7990610) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
[385 ms] UsbSnoop - MyDispatchPNP(f7992ee0) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
[404 ms] UsbSnoop - DispatchAny(f7990610) : IRP_MJ_PNP (IRP_MN_SURPRISE_REMOVAL)
[404 ms] UsbSnoop - MyDispatchPNP(f7992ee0) : IRP_MJ_PNP (IRP_MN_SURPRISE_REMOVAL)

but it seems short... (but maybe it should be so?)

The message of similar length is at URB49:

Code: Select all

[214 ms] UsbSnoop - DispatchAny(f7990610) : IRP_MJ_INTERNAL_DEVICE_CONTROL
[214 ms] UsbSnoop - MyDispatchInternalIOCTL(f7991e80) : fdo=85adb2e0, Irp=85429008, IRQL=2
[214 ms]  >>>  URB 49 going down  >>> 
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
  PipeHandle           = 855ec914 [endpoint 0x00000005]
  TransferFlags        = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 0000001f
  TransferBuffer       = 852c6b18
  TransferBufferMDL    = 00000000
    00000000: 55 53 42 43 08 90 42 85 00 00 00 00 00 00 06 01
    00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  UrbLink              = 00000000
[215 ms] UsbSnoop - MyInternalIOCTLCompletion(f7991db0) : fido=8558a780, Irp=85429008, Context=856ad288, IRQL=2

Does it look better?

And how do I find value for MessageEndpoint ?

Thanks

Morg

[Josh]

ok so the last message before "surprise removal" is here (URB 52)
...
but it seems short... (but maybe it should be so?)

I assume this sequence is sent over and over again until the switching occurs, interrupting any transfer. So you take the last completed transfer - did you do that?

And how do I find value for MessageEndpoint ?

Luckily, this is not terribly hard

Look at the line with the PipeHandle:

Code: Select all

PipeHandle           = 855ec914 [endpoint 0x00000005]

Do you see it? That's all you need ...

[morgwai]

Look at the line with the PipeHandle:

Code: Select all

PipeHandle           = 855ec914 [endpoint 0x00000005]

Do you see it? That's all you need ...

Forgive me my blindness...


Ok, so I've tried this sequence from URB 49 and it works!
So there are probably two types of this card as the sequence in original config file is also known to work for many people.
Also I looked carefully at the box of my card and it doesn't say "7.2 ready" anywhere but just "7.2" so maybe after the upgrade to real 7.2 the sequence has changed...
Anyway my /etc/usb_modeswitch.conf file looks like this:

Code: Select all

DefaultVendor=  0x05c6
DefaultProduct= 0x1000

TargetVendor=   0x0af0
TargetProduct=  0x6701

MessageEndpoint=0x05
MessageContent="55534243089042850000000000000601000000000000000000000000000000"

The timing issue exists only in "not too early" form, so I can call usb_modeswitch several minutes after plugging the card in. I've set my delay to 3s and it seems to work stable.

Thank you very much for your help and for usb_modeswitch tool of course!!!

[Josh]

So there are probably two types of this card as the sequence in original config file is also known to work for many people.
Also I looked carefully at the box of my card and it doesn't say "7.2 ready" anywhere but just "7.2" so maybe after the upgrade to real 7.2 the sequence has changed...

I will update the page and the config file to reflect that.

Did you update firmware/drivers? Or was it manufactured quite recently?

Anyway, I consider this a dirty trick ... but you showed them!

[morgwai]

I didn't update anything. I bought this card few weeks ago from my provider so it was probably manufactured recently. I looked at their web page and they also advertise it as just "7.2" not "7.2 ready" ( http://www.era.pl/pl/biznes/taryfy/blue ... komputerze ) however the model number is the same as for "7.2 ready" - GX0201

Cheers

Morg