USB_ModeSwitch

You guys really made me take up a decent fight with "udev"

I had already realized that this sometimes greedy demon did not let go of the endpoints (0x05 and 0x84 for Option). As I stated above, the switching DOES work, and "udevmonitor" shows how the storage device is removed. Eventually these endpoints are removed - and in the next moment they're added again. This repeats several times. Strange but true ...

Just now I played around with a command to reset these endpoints and found a working solution, at least for my setup. I'm releasing a new beta version; please read the new entry in the announcement forum!

No more fiddling with timings - I can switch anytime I want now

Thx for the new beta.

Now, the device switches, the usb-storage device is deregistered. But nothing more happens. modprobe usbserial/option manually doesn't seem to have any effect... and there's no new device in /dev to communicate with (there's also no one at /proc/bus/usb).

floschi, did you give "usbserial" the IDs of the (switched) device?

Plugging in the stick and running usb_modeswitch:
Then loading the usbserial and option:
only the following appered in messages:

I have no experience with the new Option firmware. You probably have to use the HSO driver. Until now I lived under the impression that there was a choice between standard kernel modules and this new thing.

The "option" module would need to know the specific IDs of the device it's supposed to bind to. If that ID is found the module is loaded and uses usbserial itself.
But even in 2.6.24.3 the device ID of your card is not listed yet (see "drivers/usb/serial/option.c").

Thx, it seems that the hso driver will work - sometimes

Josh wrote:only the system somehow does not "let go" of the device to make the change visible, if the switch tool is used too late.

I wonder whether telling the SCSI subsystem to release it using something like

echo "scsi remove-single-device 0 0 0 0" > /proc/scsi/scsi

would help in this case?

That's what I had targeted next - but since I issue a "clear_endpoint_halt" before initiating the switch all my problems vanished !!

I don't need any delays now and on the other hand can switch at any time later. And this way I don't need to wait for the SCSI layer.

Pity I don't get test results from others; they probably use "rezero" now.

Ok, I finally got around to test the HSO driver. I've tried on two cards, the "GT MAX HSUPA" and a firmware updated "GT MAX 7.2 READY".

The "GT MAX HSUPA" (Vendor=0af0 ProdID=7011) works fine. The option driver works no more, and usb_modeswitch works with the following settings:

usb_modeswitch -v 0x0af0 -p 0x7011 -m 0x05 -M 55534243123456780000000000000601000000000000000000000000000000

I used the connect script that came with the driver, sligtly modified since my resolv.conf is in anouther location and my /tmp/ directory is write protected (don't ask why...)

As others has mentioned, timing was important. I load the hso driver first, then wait 3 seconds, run usb_modeswitch, wait 1 second then run the chat script.


The "GT MAX 7.2 READY" was a little bit different. Berfore the firmware upgrade it had the product code Vendor=05c6 ProdID=1000 before the usb_modeswitch and Vendor=0af0 ProdID=6701 after.

The old option driver worked with the card before the upgrade, but not after. After the upgrade I had to use the HSO driver. I have both as modules and only load the one I use at the moment (using insmod, no fancy pants stuff here).

Once I upgraded the firmware the codes changed, now they are ALWAYS Vendor=0af0 ProdID=6711, before and after the switch. The timings and scripts were exactly the same as the other card, except the product code in the usb_modeswitch call of course.

I do have a problem with getting pppd to work. Right now I call chat myself and set up the hso0 interface. Works for me, but I'll continue to try with pppd.

And don't worry Josh, I'll never switch to rezero. Create a SCSI device just to remove it? Pffth! Stupid!

Hi all!

I own one of those devices (Vendor=0af0 ProdID=6711) to be as precise as possible and I tried to make sense of this thread, but I failed so far.

I did not have any success switching that device so far, though I understand, others had?

Did I get it right that usb_modeswitch is one way to do this while the hso / option drivers might be another one or will I still need usb_modeswitch even with the option / hso drivers?

Unfortunately, the Option driver does not yet contain this device, so I would love to make this work using usb_modeswitch.

Please let me know what information I could provide to help find any potential open issues.

Regards,
Torsten

Have you tried HSOConnect? It's a program for linux that helps you conect using the hso drivers:
http://www.pharscape.org/component/opti ... orum/f,15/

If that doesn't work, try this usb_modeswitch command:

usb_modeswitch -v 0x0af0 -p 0x6711 -m 0x05 -M 55534243123456780000000000000601000000000000000000000000000000

It should make the "fake CD" unit disappear, and then you can use the modem with the hso drivers.

I'm not on my linux machine right now, but I suspect you have to add the product/vendor codes to the hso driver yourself before compiling it if they are not there already. Just look for the id_table list in there somewhere.

Hope this helps
/ Jocke

Hi Jocke!

I got this working now. Indeed HSOConnect was a useful hint. Interesting enough, it does not work with umtsmon (http://umtsmon.sourceforge.net/).

Ok, I will research this probably later.

I still haven't fully understood how the hso, option and usb_serial drivers relate.

I am running a pretty recent kernel (2.6.27-rc4). In that version, the hso driver at least knows this device, which is vendor 0x0af0 and device 0x6971, by the way. You had a different device ID in your post.

Regards,
Torsten