[borizz]

Hello,

I'm currently kitting out a Raspberry Pi (default Debian distro) with a ZTE MF190 (19d2:2000 needs to switch to 19d2:0017). This works fine if I plug it in after the Pi has booted. However, it does not work if it boots with the stick already in there. I'd like it to work on boot because the device will be in a hard to reach place so I don't want to replug it when the power is lost.

I've turned on debuglogging and found that udev runs this usb_modeswitch -I -W -D -s 20 -u -1 -b 1 -g 5 -v 19d2 -p 2000 -f $configBuffer

I think I need to know what the configBuffer is. I suspected the message strings, but grabbing the message strings and doing this: usb_modeswitch -I -W -D -s 20 -u -1 -b 1 -g 4 -v 19d2 -p 2000 -V 19d2 -P 0017 -f -M 5553424312345678000000000000061e000000000000000000000000000000 -2 5553424312345679000000000000061b000000020000000000000000000000 -3 55534243123456702000000080000c85010101180101010101000000000000

Does not work. Note how the MessageContent is an empty string. How did that happen? I think I did this correctly with -M
(I snipped a lot of the reading long config from command line spam)

Code: Select all

Reading long config from command line

Reading long config from command line

 * usb_modeswitch: handle USB devices with multiple modes
 * Version 1.2.3 (C) Josua Dietze 2012
 * Based on libusb0 (0.1.12 and above)

 ! PLEASE REPORT NEW CONFIGURATIONS !

DefaultVendor=  0x19d2
DefaultProduct= 0x2000
TargetVendor=   0x19d2
TargetProduct=  0x0017
TargetClass=    not set
TargetProductList=""

DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
QisdaMode=0
GCTMode=0
KobilMode=0
SequansMode=0
MobileActionMode=0
CiscoMode=0
MessageEndpoint=  not set
MessageContent=""
MessageContent2="5553424312345679000000000000061b000000020000000000000000000000"
MessageContent3="55534243123456702000000080000c85010101180101010101000000000000"
NeedResponse=0
ResponseEndpoint= not set

InquireDevice disabled
Success check enabled, max. wait time 20 seconds
System integration mode enabled


Use given bus/device number: 001/004 ...
usb_set_debug: Setting debugging level to 15 (on)
usb_os_find_busses: Found 001
usb_os_find_devices: couldn't get connect info
usb_os_find_devices: Found 006 on 001
usb_os_find_devices: couldn't get connect info
usb_os_find_devices: Found 003 on 001
usb_os_find_devices: couldn't get connect info
usb_os_find_devices: Found 002 on 001
usb_os_find_devices: couldn't get connect info
usb_os_find_devices: Found 001 on 001
error obtaining child information: Operation not permitted
error obtaining child information: Operation not permitted
error obtaining child information: Operation not permitted
error obtaining child information: Operation not permitted
Looking for default devices ...
 No devices in default mode found. Nothing to do. Bye.

usb_modeswitch -c 19d2:2000 also doesn't work (I extracted the packed config files).

So, how can I switch a device that has been plugged in since boot? Can I poke udev to reevaluate? Do I need to invoke usb_modeswitch with more commands?

Any help is greatly appreciated.

[LOM]

Remove the -f switch when you have the messages on the cmd line.

[borizz]

Ok, I got it. I made a bash script:

Code: Select all

#!/bin/bash
configBuffer=$(<19d2\:2000)
usb_modeswitch -I -W -D -s 20 -u -1 -b 1 -g 4 -v 19d2 -p 2000 -f "$configBuffer"

Now, if I run that as root, it'll swap. Now all I need to do is have that script run on boot, and I'm golden.

This can be marked as solved, but I'd still like to see this being done on boot by default.

[Josh]

The original (upstream) package of usb_modeswitch usually has no problem with mode-switching during boot-up.
AFAIK, this is true for the Debian package as well.

The question is if the Debian distribution was trimmed or downsized for the Raspberry?

There may also be issues with the USB host hardware/drivers, judging from some reports in this forum (use search feature).

[mthiede]

Hello,

I have pretty much the same problem with a Raspberry Pi (2012-12-16 wheezy) and a Huawei E173s.
After a cold boot, the device won't be switched.
After a reboot it works.
After a cold boot I can switch manually be doing "sudo udevadm trigger".
Using usb_modeswitch 1.2.3.

I think that usb_modeswitch is called correctly in all cases.
Below is the diff of file /var/log/usb_modeswitch_1-1.3\:1.0 between the good case and the bad case:
* in the "bad" case the time is not yet set via NTP
* in the "bad" case there is a driver attached whereas in the "good" case there is no driver

Could one of these be the reason for the failure?

Martin

Code: Select all

3c3
< USB_ModeSwitch log from Thu Jan  01 00:00:05 UTC 1970
---
> USB_ModeSwitch log from Sat Feb  09 21:39:54 UTC 2013
86,87c86
<  OK, driver found ("usb-storage")
<  OK, driver "usb-storage" detached
---
>  No driver found. Either detached before or never attached
93a93,94
>  Could not reset endpoint (probably harmless): -9
>  Device is gone, skipping any further commands
101,132c102,115
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<  Reading attributes ...
<
< Target config not matching - current values are
<     1-1.3:1.0/bInterfaceClass: 08
<     bConfigurationValue:       1
<     bNumConfigurations:        1
<     busnum:                    1
<     devnum:                    4
<     idProduct:                 1c0b
<     idVendor:                  12d1
<     manufacturer:              HUAWEI
<     product:                   HUAWEI Mobile
<     serial:
---
>  Waiting for device file system (1 sec.) ...
>  Waiting for device file system (2 sec.) ...
>  Waiting for device file system (3 sec.) ...
>  Waiting for device file system (4 sec.) ...
>  Waiting for device file system (5 sec.) ...
>  Waiting for device file system (6 sec.) ...
>  Reading attributes ...
>  All attributes matched
> Mode switching was successful, found 12d1:1c05 (HUAWEI: HUAWEI Mobile)
> Logger is /usr/bin/logger
> Now checking for bound driver ...
>  driver has bound, device is known
> Checking for AVOID_RESET_QUIRK kernel attribute
>  AVOID_RESET_QUIRK activated
134c117
< Mode switching may have failed. Exiting
---
> All done, exiting