[Josh]

There is one last desperate measure to try - resetting the device immediately before sending the control sequence. Some more hacking required. Stand by.

[The Solutor]

Stand by.

My red led is blinking...

In the meantime I'm looking on an old Mac G4 if I can understand anything else. (the key is supported on MACs trough a 3rd party sw)

[Josh]

I found still annother source of error in our quest.

Would you test this version please?

I provide the source since you are on 64bit; plus you can activate the reset code yourself, if the other trick does not show results. Look for "MD400" in the code.

Good Luck!

[The Solutor]

I found still annother source of error in our quest.

Would you test this version please?

I provide the source since you are on 64bit; plus you can activate the reset code yourself, if the other trick does not show results. Look for "MD400" in the code.

Tabks, I'll test asap, tough today is a busy day for me.

Maybe I can't test your code until the next year.

P.S. abandoned for now the idea of looking what happen in MacOS: I installed the official usb monitor from apple developer site, and then I lost all the usb functionality and is not a nice thing on a machine w/o any other mouse and kb connection.

[The Solutor]

Good news

the custom version forces the modem to switch, but after a bunch of seconds the modem switches back to the storage mode.

But i realized that it's official, I'm stupid

I simply initialized the modem from windows then I chacked the value used in the md300 with a

cat /sys/bus/usb/devices/1-8/bConfigurationValue

And the result is 2 !

so i unplugged and replugged the modem

and the command

echo 2 > /sys/bus/usb/devices/1-8/bConfigurationValue
has forced the modem to change his mind

Maybe "2" was the only value that I' havent tried before.

So, the udev rule linked above can be sufficient to do the job just changing the PID value ant the configuration value from 3 to 2 (havent tested it but I'm sure it works).

[Josh]

That's what the log says too. After the switching command and the device querying the next thing the driver sends is the configuration request:

Code: Select all

-- URB_FUNCTION_SELECT_CONFIGURATION:
  ConfigurationDescriptor = 0x85717568 (configure)
  ConfigurationDescriptor : bLength             = 9
  ConfigurationDescriptor : bDescriptorType     = 0x00000002
  ConfigurationDescriptor : wTotalLength        = 0x00000164
  ConfigurationDescriptor : bNumInterfaces      = 0x0000000a
  ConfigurationDescriptor : bConfigurationValue = 0x00000002
  ConfigurationDescriptor : iConfiguration      = 0x00000006
  ConfigurationDescriptor : bmAttributes        = 0x00000080
  ConfigurationDescriptor : MaxPower            = 0x000000fa 

O.K., I'll brush up the code and include that special sequence. No problem to add the configuration selection right away. But first, please give me some answers (as precisely as possible):

- did you test with usb-storage enabled? Does it work as well?
- did you have to enable the reset code?
- does the recognition of the class work (TargetClass 0x02) if you call usb_modeswitch again after switching?

Thanks!

And Hooray

[Josh]

Just for clarification, maybe I didn't get it right:

Do you need the custom usb_modeswitch for switching or is the configuration selection via "echo" sufficient without any special tools?

[The Solutor]

Sorry for the late reply.

I start from the end...

Just for clarification, maybe I didn't get it right:

Do you need the custom usb_modeswitch for switching or is the configuration selection via "echo" sufficient without any special tools?

This is what I got: simply switching back and forth via echoing 1 or 2, but after a reboot I wasn't able to doing it anymore.

I did something that I can't reproduce anymore

Sadly I still can switch from modem mode to storage mode echoing "1", but I cant't do the reverse process: whenever I echo "2" I get an error
bash: echo: write error: Invalid argument

O.K., I'll brush up the code and include that special sequence. No problem to add the configuration selection right away. But first, please give me some answers (as precisely as possible):

- did you test with usb-storage enabled? Does it work as well?

Yes, it works both with or without the usb-sotrage module

- did you have to enable the reset code?

It works without the reset code enabled, if I enable the reset code it works only if the storage driver is missing.

In any combiation (with or without the reset code, with or w/o the usb-storage module) the output of usb_modeswitch is

Code: Select all

./usb_modeswitch -v 0x0fce -p 0xd0e1 -H 

....

 Found default devices (1)
Prepare switching, accessing latest device
Error: sending Sony control message failed (error 3). Aborting

- does the recognition of the class work (TargetClass 0x02) if you call usb_modeswitch again after switching?

Sorry I can't understand, do you mean rerunning usb_modeswitch during the few seconds when the device is in modem mode or do you mean rerunning usb_modeswitch after the tevices has switched back to storage mode ?

[The Solutor]

I almost forgot two things

Carl Nordbeck has replied to the my mail with (a bit cryptic)
"You must switch the configuration to the second one...

"Preferably this is done by a udev rule? You can match the VID/PID to MD400 and set the second configuration."

I suppose he is speaking about the same ecoing way posted above, that worked once.

I looked on the kernel tree and I discovered the file unusal_devs.h already used for the huawei 220 and some other similar devices, so I posted the problem on the usb-storage mailing list (linking also this tread) to see if the problem can ba solved also at the kernel level.

Would be nice to have both the solution: usb_modeswitch or an udev rule for the near future (and for everione is not comfortable with the kernel updates) and the patched kernel handy for the next generation of distros and for the power users that are used to complile and update his kernels.

[Josh]

Thanks for the update. I thought I'd put together a list of all the results so far. Please check it and comment if you object:

1. Freshly plugged MD can be switched reliably to modem by setting configuration 2 in the sys tree directly, but not back to storage
2. Freshly plugged MD can be switched to modem by the special sequence in usb_modeswitch (test version, no reset), but switches back after some time
3. Both switching methods are working regardless of an active usb-storage driver
4. The device class of the MD changes to 2 after switching

You can check the last item if you call usb_modeswitch (test version) with the TargetClass parameter, like this:

Code: Select all

./usb_modeswitch_sony -v 0x0fce -p 0xd0e1 -H 1 -C 0x02

If the device is switched to modem already - regardless how it was done - this call should result in doing nothing. That's what I meant with class recognition. I just want to make sure usb_modeswitch can recognize the switched and unswitched state.

One last thing (hopefully): what's the output of "udevmonitor" during both ways of switching?
Sorry for pestering you with so many questions; it's the only way to get reliable information since I don't have access to all these devices.

[The Solutor]

[*]Freshly plugged MD can be switched reliably to modem by setting configuration 2 in the sys tree directly, but not back to storage

No, this is what I had only once.

On the other hand, putting the value 1 in the sys tree (when in modem mode), switches the device to storage mode, an this always works.

Freshly plugged MD can be switched to modem by the special sequence in usb_modeswitch (test version, no reset), but switches back after some time

Correct

Sorry for pestering you with so many questions; it's the only way to get reliable information since I don't have access to all these devices.

No problem at all, you are wellcome !

Both switching methods are working regardless of an active usb-storage driver

Usb_modeswitch works regardless the usb_driver if the reset code isn't enabled

For the echo method see above

The device class of the MD changes to 2 after switching
[...]
If the device is switched to modem already - regardless how it was done - this call should result in doing nothing

OK, the following output is from the device in storage mode

Code: Select all

Looking for default devices
 Found default devices (1)
 OK, found default device not in target class mode
Prepare switching, accessing latest device
Error: sending Sony control message failed (error 3). Aborting

And this is when in modem mode:

Code: Select all

Looking for default devices
 Found default devices (1)
 All devices in target class mode
 No default device found. Is it connected? Bye

One last thing (hopefully): what's the output of "udevmonitor" during both ways of switching?

When the device is plugged for the first time

Code: Select all

UEVENT[1230923367.617576] add      /devices/pci0000:00/0000:00:13.3/usb1/1-6 (usb)
UEVENT[1230923367.618509] add      /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0 (usb)
UEVENT[1230923367.619611] add      /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/host24 (scsi)
UEVENT[1230923367.619814] add      /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/host24/scsi_host/host24 (scsi_host)
...
UDEV  [1230923372.807931] add      /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/host24/target24:0:0/24:0:0:1/block/sdi (block)
UDEV  [1230923372.868005] add      /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/host24/target24:0:0/24:0:0:0/block/sdh (block)
UDEV  [1230923372.930772] add      /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/host24/target24:0:0/24:0:0:0/block/sdh/sdh1(block)

I'll continue in the follwing post because the board cuts the long messages.

[The Solutor]

When the command

usb_modeswitch -v 0x0fce -p 0xd0e1 -H 1

is sent

Code: Select all

UEVENT[1230923579.184380] remove   /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/usb_endpoint/usbdev1.23_ep01 (usb_endpoint)
UEVENT[1230923579.184472] remove   /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/usb_endpoint/usbdev1.23_ep81 (usb_endpoint)
UEVENT[1230923579.184584] remove   /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/host24/target24:0:0/24:0:0:0/bsg/24:0:0:0 (bsg)                                                                                                                              
...
UDEV  [1230923652.245125] add      /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/host26/target26:0:0/26:0:0:0/block/sdh (block)
UDEV  [1230923652.316369] add      /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/host26/target26:0:0/26:0:0:0/block/sdh/sdh1(block)
UDEV  [1230923652.470600] change   /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/host26/target26:0:0/26:0:0:0/block/sdh (block)

Sorry for pestering you with so many questions; it's the only way to get reliable information since I don't have access to all these devices.

No problem at all, You are wellcome

[Josh]

Wow, cool!

Thanks for all the info!

Now I know that the device seems to keep its connections to the USB system open (and not vanishing and coming back like other devices).

I added the configuration change to the "Sony sequence" in the source file (the link that you used before). You can try if this helps in switching permanently.

Good luck! But I think we're close

[The Solutor]

Wow, cool!

Thanks for all the info!

Now I know that the device seems to keep its connections to the USB system open (and not vanishing and coming back like other devices).

I added the configuration change to the "Sony sequence" in the source file (the link that you used before). You can try if this helps in switching permanently.

Good luck! But I think we're close

Still switches back to config 1


This is the reply on the terminal:

Code: Select all

Looking for default devices
 Found default devices (1)
Prepare switching, accessing latest device
 OK, Sony control message successfully sent.
 Setting configuration to 2 returned: -16
-> See /proc/bus/usb/devices (or call lsusb) for changes. Bye

An this is the output of udevmonitor. (no reference to mb0 device because in this moment I'm on an unpatched kernel)

Code: Select all

UEVENT[1230944628.380975] remove   /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/usb_endpoint/usbdev1.24_ep01 (usb_endpoint)
UEVENT[1230944628.382540] remove   /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/usb_endpoint/usbdev1.24_ep81 (usb_endpoint)
UDEV  [1230944628.382575] remove   /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/usb_endpoint/usbdev1.24_ep01 (usb_endpoint)
...
UDEV  [1230944700.844006] add      /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/host25/target25:0:0/25:0:0:1/scsi_device/25:0:0:1 (scsi_device)
UDEV  [1230944701.071195] add      /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/host25/target25:0:0/25:0:0:0/block/sdh (block)
UDEV  [1230944701.136766] add      /devices/pci0000:00/0000:00:13.3/usb1/1-6/1-6:1.0/host25/target25:0:0/25:0:0:0/block/sdh/sdh1 (block)

[The Solutor]

I'm not a programmer, but on what I can understand from your code

the first message from my logs is sent ( 5a 11 02 )

the device needs to recive the second one too ?

(1201000200000040ce0fe1d0000001020301)