Hi all,
a few minutes ago I got a new USB UMTS HSDPA Modem from T-Mobile.
It is marked "web'n'walk Stick" on the front side,
"QUALCOMM 3G CDMA" on the rear side.
And it has the "ZeroCD" feature.
After plugging in, it was recognized as following:
----------------------------------------------------------------------------------
T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 7 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0af0 ProdID=6971 Rev= 0.00
S: Manufacturer=Option N.V.
S: Product=Globetrotter HSDPA Modem
S: SerialNumber=Serial Number
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
----------------------------------------------------------------------------------
There is no example configuration for this device (ProdID=6971)
in the usb_modeswitch.conf. Can someone help me with it?
Thanks in advance!
B.M.
The IDs (Vendor=0af0, ProdID=6971) give a hint that this is one of the new Option devices which uses the same IDs for storage and modem mode.
Get the 0.9.3beta version (if you don't have it already) and use the "GlobeSurfer Icon 7.2, new firmware" entry, replacing the line
with your value:
The switching command should be the same - in theory, that is 
Please confirm if it's working so we can add this new device to the list (obviously it's available from Vodafone as well).
Get the 0.9.3beta version (if you don't have it already) and use the "GlobeSurfer Icon 7.2, new firmware" entry, replacing the line
Code: Select all
DefaultProduct= 0x6911Code: Select all
DefaultProduct= 0x6971Please confirm if it's working so we can add this new device to the list (obviously it's available from Vodafone as well).
-
Sullen_scrota
- Posts: 3
- Joined: 18 Feb 2008, 18:56
-
Sullen_scrota
- Posts: 3
- Joined: 18 Feb 2008, 18:56
-
Sullen_scrota
- Posts: 3
- Joined: 18 Feb 2008, 18:56
Delivery to the following recipients failed.
usb_admin@draisberghof.de
webmaster@draisberghof.de
Where do I send it ?
usb_admin@draisberghof.de
webmaster@draisberghof.de
Where do I send it ?
I've attempted a capture for one of these devices using W2K, I get the same results trying to email it.Sullen_scrota wrote:Delivery to the following recipients failed.
usb_admin@draisberghof.de
webmaster@draisberghof.de
Where do I send it ?
I've temporarily uploaded the result to http://www.jfgtelemetry.ltd.uk/ephemera ... oop.log.gz
Sorry, folks, after the move to the new provider these addresses were reset.
Please use "usb_admin", it should work now.
Besides, I have accumulated fresh knowledge. I changed the hardware of my little router and installed a more recent distro. And suddenly, my Option Icon - which never had problems switching at the old machine - refused to flip out of storage mode. I played around with the timing, and the result was like this:
- Up to 2 seconds after plugging in: NO switching
- 5 seconds (and ANY time later) after plugging in: NO switching
- In between: FINE switching
SAME device, different environment. (Udev is definitely under suspicion in my case.)
My conclusion is that most of the individual problems people are running into are NOT caused by the devices themselves but by the different and changing hotplugging mechanisms.
So my advice concerning Option devices is: try different timings. The command for switching has NOT changed from the first devices (like my Icon).
Please use "usb_admin", it should work now.
Besides, I have accumulated fresh knowledge. I changed the hardware of my little router and installed a more recent distro. And suddenly, my Option Icon - which never had problems switching at the old machine - refused to flip out of storage mode. I played around with the timing, and the result was like this:
- Up to 2 seconds after plugging in: NO switching
- 5 seconds (and ANY time later) after plugging in: NO switching
- In between: FINE switching
SAME device, different environment. (Udev is definitely under suspicion in my case.)
My conclusion is that most of the individual problems people are running into are NOT caused by the devices themselves but by the different and changing hotplugging mechanisms.
So my advice concerning Option devices is: try different timings. The command for switching has NOT changed from the first devices (like my Icon).
So from my position of having very little USB experience and wanting to eliminate as many unknowns as possible where do you think we are with this particular device? Are these the appropriate settings:Josh wrote: ... My conclusion is that most of the individual problems people are running into are NOT caused by the devices themselves but by the different and changing hotplugging mechanisms.
So my advice concerning Option devices is: try different timings. The command for switching has NOT changed from the first devices (like my Icon).
> Get the 0.9.3beta version (if you don't have it already) and use the
> "GlobeSurfer Icon 7.2, new firmware" entry, replacing the line
>
> Code:
> DefaultProduct= 0x6911
>
> with your value:
> Code:
> DefaultProduct= 0x6971
>
> The switching command should be the same - in theory, that is
I wonder whether there is some way of telling the hotplug daemon to ignore this particular device or if this would have to be done in the kernel mass storage module?
Well, where do we stand?
I really have not much of an idea. My problem is - as always - that I don't have the device here and I don't know the fine mechanics of all the distros around ...
I can only give the advice to use a delaying script as described on the USB_ModeSwitch page. When I found out about the timing issue on my new machine (by plugging in and starting usb_modeswitch manually after a delay) I used the tiny delaying script with the udev entry and had a working system ever since.
In most systems, there is the way of the blacklist file where you can list kernel modules to prevent them from loading automatically. The trouble is that you can forget about using any storage device like flash sticks and MP3 players if you blacklist the usbstorage module.
There might be more subtle ways in the udev world, but that is not my field of knowledge. I say, don't tamper with the "convenience" functions like hotplugging more than necessary. It's probably not even udev itself where the trouble lies but distribution-specific mechanisms to mount USB storage devices into the file system automatically. Which is generally what we want, just not in this special case.
The basic trouble is, what we are doing here is trying to find a way around one of the central features of USB: every device announces itself and it's basic function with the one purpose of attaching to the right driver without any ambiguities.
I really have not much of an idea. My problem is - as always - that I don't have the device here and I don't know the fine mechanics of all the distros around ...
I can only give the advice to use a delaying script as described on the USB_ModeSwitch page. When I found out about the timing issue on my new machine (by plugging in and starting usb_modeswitch manually after a delay) I used the tiny delaying script with the udev entry and had a working system ever since.
In most systems, there is the way of the blacklist file where you can list kernel modules to prevent them from loading automatically. The trouble is that you can forget about using any storage device like flash sticks and MP3 players if you blacklist the usbstorage module.
There might be more subtle ways in the udev world, but that is not my field of knowledge. I say, don't tamper with the "convenience" functions like hotplugging more than necessary. It's probably not even udev itself where the trouble lies but distribution-specific mechanisms to mount USB storage devices into the file system automatically. Which is generally what we want, just not in this special case.
The basic trouble is, what we are doing here is trying to find a way around one of the central features of USB: every device announces itself and it's basic function with the one purpose of attaching to the right driver without any ambiguities.
A colleague has volunteered to head in your direction with this device when he's next in GermanyJosh wrote:My problem is - as always - that I don't have the device here and I don't know the fine mechanics of all the distros around ...
I'll investigate delay script etc.
The problem as I see it is that in cases where the device ID changes after modeswitch we might be able to tell the hotplugging mechanism to ignore (or something) the original device, however in the current case this might be more difficult since the ID appears to be the same before and after the modeswitch.Josh wrote:The basic trouble is, what we are doing here is trying to find a way around one of the central features of USB: every device announces itself and it's basic function with the one purpose of attaching to the right driver without any ambiguities.
I'll continue tinkering and report back if I get anywhere interesting. Or if I find myself totally lost.
I get exactly the same problem - nothing happens. But it seems that one user solved this: http://www.draisberghof.de/usb_modeswit ... c.php?t=52 ?
Or do I misunderstand that posting?
Or do I misunderstand that posting?
The Option Icon 225 aka "T-Mobile web'n'walk Stick" is confirmed working.
It's again a matter of timing depending on the specific hot-plug/udev system. Try a manual start of USB_ModeSwitch after plugging the device in, starting from 1 second delay and going up to 5 or 6. That's really all I can say.
It's again a matter of timing depending on the specific hot-plug/udev system. Try a manual start of USB_ModeSwitch after plugging the device in, starting from 1 second delay and going up to 5 or 6. That's really all I can say.
-
Direc
I have it working... most of the time, that is. I think it's the timing issue that keeps it from working every time... I'll go to mom's this weekend (she actually uses it, I live in a ADSL-reachable area) so then I can test it.
What about rezero utility? I'm using it now, and I think it works at least more often than usb_modeswitch... We should find out what happens when Windows drivers switching is delayed... But then again, when I test-installed it, the installation process surely took more than five seconds! And then it just switched to modem mode and I could connect... So perhaps the usb_modeswitch way isn't the best way... How it differs from usb_modeswitch?
What about rezero utility? I'm using it now, and I think it works at least more often than usb_modeswitch... We should find out what happens when Windows drivers switching is delayed... But then again, when I test-installed it, the installation process surely took more than five seconds! And then it just switched to modem mode and I could connect... So perhaps the usb_modeswitch way isn't the best way... How it differs from usb_modeswitch?
The rezero utility uses the SCSI driver to access the device, which sits on the USB layer after usb-storage is grabbing the device.
The command sent is basically the same. I just use the USB "entrance".
They don't detach any driver though, I wonder if that makes any difference. I'll check.
As I know from a debug run of "udev", the switching via USB_ModeSwitch really seems to work EVERY time - only the system somehow does not "let go" of the device to make the change visible, if the switch tool is used too late.
The command sent is basically the same. I just use the USB "entrance".
They don't detach any driver though, I wonder if that makes any difference. I'll check.
As I know from a debug run of "udev", the switching via USB_ModeSwitch really seems to work EVERY time - only the system somehow does not "let go" of the device to make the change visible, if the switch tool is used too late.