[hoppy]

Hi,

I've got Ubuntu 9.10. I'm completely up to date (apt-get upgrade) and I've got usb_modeswitch (1.6.1) (data and code). I have an O2 Huawei E1752 dongle.

usb_modeswitch -c /etc/usb_modeswitch.d/12d1\:1446 works fine if the device is plugged in.

However usb_modeswitch does not get triggered on boot, nor does it get triggered if I plug the device in.

If I try running the usb_modeswitch command with the dongle plugged in on reboot, the command hangs. However if I then replug the device, the command succeeds.

I'm looking to get into the position where the device gets switched automatically on boot/reboot or replug.

Will it be something in udev that's not triggering???

Thanks for any help.

(Note I've changed the 12d1:1446 file in /etc/usb_modeswitch.d so that it works - as advised by other threads. The original content doesn't seem to work with this key!)

)
HoPpY

[Josh]

Hmm, I tested on Ubuntu 9.04 and it worked ...

I suspect there are interferences with other udev rules. Try a "grep 1446 *" in "/lib/udev/rules.d" and probably in "/etc/udev/rules.d". The only occurence of that ID should be in the rules file of usb_modeswitch.

May I ask how exactly you changed the config file "12d1:1446" ?

[hoppy]

There are no files with 1446 in them in /etc/udev/rules.d. However, there are two files in /lib/udev/rules.d as follows:

40-usb_modeswitch.rules:

ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1446", RUN+="usb_modeswitch '%b/%k'"

61-option-modem-modeswitch.rules:

ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1446", RUN+="modem-modeswitch -v 0x%s{idVendor} -p 0x%s{idProduct} -t option-zerocd"

So possibly some conflict here is my problem - maybe two programs trying to do the same thing?

Here is my changed 12d1:1446 file:

########################################################
# Huawei, newer modems

DefaultVendor= 0x12d1
DefaultProduct=0x1446

TargetVendor= 0x12d1
TargetProductList="1001,1406,140b,140c,1412,141b,1436,14ac"

CheckSuccess=20

MessageContent="55534243000000000000000000000011060000000100000000000000000000"
#MessageContent="55534243123456780000000000000011062000000100000000000000000000"

Thanks,

HoPpY

Hmm, I tested on Ubuntu 9.04 and it worked ...

I suspect there are interferences with other udev rules. Try a "grep 1446 *" in "/lib/udev/rules.d" and probably in "/etc/udev/rules.d". The only occurence of that ID should be in the rules file of usb_modeswitch.

May I ask how exactly you changed the config file "12d1:1446" ?

[Josh]

That file "61-option-modem-modeswitch.rules" is the source of the problem. It is known to cause trouble.
Edit it and insert a "#" character in front of the line with "1446" to disable the entry.

Then you should be able to have your device switched automatically every time.

[hoppy]

Hmmm. Not quite. Before you posted this, I also moved the file away. It doesn't seem to make a difference.

I tried enabling usb_modeswitch logging, but nothing appears in /var/log.

So I'm guessing that something isn't triggering somewhere.

lsusb always shows that the device is there with it's 12d1:1446 vid/pids, and running usb_modeswitch -c /etc/usbmodeswitch.d/12d1:1446 mostly seems to work.

Any idea how we can debug why udev isn't triggering the usb_modeswitch - if indeed that is what is happening? Is there a clean way of removing modem-modeswitch?

To install the usb_modeswitch (code and data) I used dpkg on the .deb files on a USB key. Was there any other installation steps I needed to perform?

Thanks for your help so far - gratefully received!

)
HoPpY

That file "61-option-modem-modeswitch.rules" is the source of the problem. It is known to cause trouble.
Edit it and insert a "#" character in front of the line with "1446" to disable the entry.

Then you should be able to have your device switched automatically every time.

[Josh]

Just to be on the safe side - did you install the "tcl" package?

[hoppy]

Yes, it is installed.

I'm fairly convinced this is down to udev not triggering the usb_modeswitch rule(s) for whatever reason but I can't work out why. As soon as I issue the usb_modeswitch -c command by hand it always seems to work.

So for me, we need to confirm if udev is matching the rule for 02d1:1446 and if not then why not?

Can we put some sort of debug/trace information in the usb_modeswitch.rules file to see what is happening?

How can we confirm that udev is reading and parsing the usb_modeswitch.rules file?

HoPpY

Just to be on the safe side - did you install the "tcl" package?

[hoppy]

Here is some info **before** the device is switched:

# udevadm info --attribute-walk --name /dev/bus/usb/001/009
custom logging function 0x28c4008 registered
selinux=0
calling: info
device 0x28c41f0 has devpath '/devices/pci0000:00/0000:00:1e.0/0000:01:0e.2/usb1/1-2'

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device '/devices/pci0000:00/0000:00:1e.0/0000:01:0e.2/usb1/1-2':
KERNEL=="1-2"
SUBSYSTEM=="usb"
DRIVER=="usb"
ATTR{configuration}=="Huawei Configuration"
ATTR{bNumInterfaces}==" 2"
ATTR{bConfigurationValue}=="1"
ATTR{bmAttributes}=="e0"
ATTR{bMaxPower}=="500mA"
ATTR{urbnum}=="5742"
ATTR{idVendor}=="12d1"
ATTR{idProduct}=="1446"
ATTR{bcdDevice}=="0000"
ATTR{bDeviceClass}=="00"
ATTR{bDeviceSubClass}=="00"
ATTR{bDeviceProtocol}=="00"
ATTR{bNumConfigurations}=="1"
ATTR{bMaxPacketSize0}=="64"
ATTR{speed}=="480"
ATTR{busnum}=="1"
ATTR{devnum}=="9"
ATTR{version}==" 2.00"
ATTR{maxchild}=="0"
ATTR{quirks}=="0x0"
ATTR{authorized}=="1"
ATTR{manufacturer}=="HUAWEI Technology"
ATTR{product}=="HUAWEI Mobile"

device 0x28c49f0 has devpath '/devices/pci0000:00/0000:00:1e.0/0000:01:0e.2/usb1'
looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:01:0e.2/usb1':
KERNELS=="usb1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}==""
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bmAttributes}=="e0"
ATTRS{bMaxPower}==" 0mA"
ATTRS{urbnum}=="197"
ATTRS{idVendor}=="1d6b"
ATTRS{idProduct}=="0002"
ATTRS{bcdDevice}=="0206"
ATTRS{bDeviceClass}=="09"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bNumConfigurations}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{speed}=="480"
ATTRS{busnum}=="1"
ATTRS{devnum}=="1"
ATTRS{version}==" 2.00"
ATTRS{maxchild}=="5"
ATTRS{quirks}=="0x0"
ATTRS{authorized}=="1"
ATTRS{manufacturer}=="Linux 2.6.31-19-generic ehci_hcd"
ATTRS{product}=="EHCI Host Controller"
ATTRS{serial}=="0000:01:0e.2"
ATTRS{authorized_default}=="1"

device 0x28c52e0 has devpath '/devices/pci0000:00/0000:00:1e.0/0000:01:0e.2'
looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:01:0e.2':
KERNELS=="0000:01:0e.2"
SUBSYSTEMS=="pci"
DRIVERS=="ehci_hcd"
ATTRS{vendor}=="0x1033"
ATTRS{device}=="0x00e0"
ATTRS{subsystem_vendor}=="0x1758"
ATTRS{subsystem_device}=="0x2001"
ATTRS{class}=="0x0c0320"
ATTRS{irq}=="11"
ATTRS{local_cpus}=="ff"
ATTRS{local_cpulist}=="0-7"
ATTRS{modalias}=="pci:v00001033d000000E0sv00001758sd00002001bc0Csc03i20"
ATTRS{enable}=="1"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""
ATTRS{companion}==""

device 0x28c5d20 has devpath '/devices/pci0000:00/0000:00:1e.0'
looking at parent device '/devices/pci0000:00/0000:00:1e.0':
KERNELS=="0000:00:1e.0"
SUBSYSTEMS=="pci"
DRIVERS==""
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x2418"
ATTRS{subsystem_vendor}=="0x0000"
ATTRS{subsystem_device}=="0x0000"
ATTRS{class}=="0x060400"
ATTRS{irq}=="0"
ATTRS{local_cpus}=="ff"
ATTRS{local_cpulist}=="0-7"
ATTRS{modalias}=="pci:v00008086d00002418sv00000000sd00000000bc06sc04i00"
ATTRS{enable}=="1"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}=="1"

device 0x28c69e0 has devpath '/devices/pci0000:00'
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""

root@BristolAeroClub:/dev/bus/usb/001# cd /etc/usb_modeswitch.d
root@BristolAeroClub:/etc/usb_modeswitch.d# usb_modeswitch -c 12d1\:1446

Looking for target devices ...
No devices in target mode or class found
Looking for default devices ...
Found devices in default mode, class or configuration (1)
Accessing device 009 on bus 001 ...
Getting the current device configuration ...
OK, got current device configuration (1)
Using endpoints 0x01 (out) and 0x81 (in)
Using endpoints 0x01 (out) and 0x81 (in)
Inquiring device details; driver will be detached ...
Looking for active driver ...
OK, driver found ("usb-storage")
OK, driver "usb-storage" detached

SCSI inquiry data (for identification)
-------------------------
Vendor String: HUAWEI
Model String: Mass Storage
Revision String: 2.31
-------------------------

USB description data (for identification)
-------------------------
Manufacturer: HUAWEI Technology
Product: HUAWEI Mobile
Serial No.: not provided
-------------------------
Setting up communication with interface 0 ...
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
Device seems to have vanished right after sending. Good.
Device is gone, skipping any further commands

Checking for mode switch (max. 20 times, once per second) ...
Searching for target devices ...
Searching for target devices ...
Searching for target devices ...
Searching for target devices ...
Searching for target devices ...
Searching for target devices ...

Found target device, now opening
Found correct target device

Mode switch succeeded. Bye.

root@BristolAeroClub:/etc/usb_modeswitch.d# lsusb
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 010: ID 12d1:140c Huawei Technologies Co., Ltd.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
root@BristolAeroClub:/etc/usb_modeswitch.d#

Yes, it is installed.

I'm fairly convinced this is down to udev not triggering the usb_modeswitch rule(s) for whatever reason but I can't work out why. As soon as I issue the usb_modeswitch -c command by hand it always seems to work.

So for me, we need to confirm if udev is matching the rule for 02d1:1446 and if not then why not?

Can we put some sort of debug/trace information in the usb_modeswitch.rules file to see what is happening?

How can we confirm that udev is reading and parsing the usb_modeswitch.rules file?

HoPpY

Just to be on the safe side - did you install the "tcl" package?

[Josh]

You can issue the command:

Code: Select all

# udevadm control --log-priority=debug

Then plug in and wait a moment. After that, you should be able to see all actions of udev in your syslog.
usb_modeswitch should be mentioned there.

Don't forget to set udev to normal logging again with:

Code: Select all

# udevadm control --log-priority=err

[hoppy]

Yes I did the same thing by editing the udev conf file.

I've also used the udevadm monitor command.

I've also simplified the udev rules file to be as below - the switch doesn't happen. It looks as though udev is seeing the add, but for some reason isn't triggering the rule to do the switch!

Here's my simplified rules file and output found in /var/log/udev:

# Part of usb-modeswitch-data, version 20101222
#
# This file is intended for USB_ModeSwitch version >= 1.1.2
# but will not break anything if used with versions >= 1.0.3
#
ACTION!="add", GOTO="modeswitch_rules_end"

# This adds a symlink "gsmmodem[n]" to ttyUSB ports with interrupt transfer;
# will work only with wrapper from 1.1.4 and above (otherwise ignored)
#HOPPY KERNEL=="ttyUSB*", ATTRS{bNumConfigurations}=="*", PROGRAM="usb_modeswitch --symlink-name %p %s{idVendor} %s{idProduct} %E{PRODUCT}", SYMLINK="%c"

SUBSYSTEM!="usb", GOTO="modeswitch_rules_end"

# This adds the device ID to the "option" driver after a warm boot
# in cases when the device is yet unknown to the driver
#HOPPY ATTR{bInterfaceClass}=="ff", ATTR{bInterfaceNumber}=="00", ATTRS{bNumConfigurations}=="*", RUN+="usb_modeswitch --driver-bind %p %s{idVendor} %s{idProduct} %E{PRODUCT}"

# Most known install partitions are on interface 0, one on 5, one on 9
#HOPPY ATTRS{bInterfaceNumber}!="0[059]", GOTO="modeswitch_rules_end"

# only storage class devices are handled; negative
# filtering here would exclude some quirky devices
#HOPPY ATTRS{bDeviceClass}=="08", GOTO="modeswitch_rules_begin"
#HOPPY ATTRS{bInterfaceClass}=="08", GOTO="modeswitch_rules_begin"
#HOPPY GOTO="modeswitch_rules_end"

LABEL="modeswitch_rules_begin"

# Huawei, newer modems
ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1446", RUN+="usb_modeswitch '%b/%k'"

LABEL="modeswitch_rules_end"

KERNEL[1294426245.272204] add /devices/pci0000:00/0000:00:1e.0/0000:01:0e.2/usb1/1-2/1-2:1.0 (usb)
UDEV_LOG=7
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1e.0/0000:01:0e.2/usb1/1-2/1-2:1.0
SUBSYSTEM=usb
DEVTYPE=usb_interface
DEVICE=/proc/bus/usb/001/002
PRODUCT=12d1/1446/0
TYPE=0/0/0
INTERFACE=8/6/80
MODALIAS=usb:v12D1p1446d0000dc00dsc00dp00ic08isc06ip50
SEQNUM=972

KERNEL[1294426245.272306] add /devices/pci0000:00/0000:00:1e.0/0000:01:0e.2/usb1/1-2/1-2:1.1 (usb)
UDEV_LOG=7
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1e.0/0000:01:0e.2/usb1/1-2/1-2:1.1
SUBSYSTEM=usb
DEVTYPE=usb_interface
DEVICE=/proc/bus/usb/001/002
PRODUCT=12d1/1446/0
TYPE=0/0/0
INTERFACE=8/6/80
MODALIAS=usb:v12D1p1446d0000dc00dsc00dp00ic08isc06ip50
SEQNUM=973

You can issue the command:

Code: Select all

# udevadm control --log-priority=debug

Then plug in and wait a moment. After that, you should be able to see all actions of udev in your syslog.
usb_modeswitch should be mentioned there.

Don't forget to set udev to normal logging again with:

Code: Select all

# udevadm control --log-priority=err

[Josh]

Hmm, what you get in that log is certainly not the whole story ...

When I set the udev debug mode on my systems, I can see every rule that matches, and there should be a lot more than the one with usb_modeswitch - all kinds of test for "blk_id", storage names etc.
Every program call that is initiated with RUN is listed with the fully expanded command line and the return result.

I don't get a separate udev log file though; it will all be written into "syslog".

[hoppy]

OK.

I've looked at syslog. I get a couple of what look like irregular outputs. It looks as though udev is running the script in /lib/udev

First of all I get this each time the script is run:

Jan 10 16:52:33 BristolAeroClub udevd-work[1891]: '/lib/udev/usb_modeswitch' (stderr) '/lib/udev/usb_modeswitch: 33: arithmetic expression: expecting EOF: "0x"'

and I also see this:

Jan 10 16:52:33 BristolAeroClub udevd-work[1891]: '/lib/udev/usb_modeswitch' (stderr) '.: 72: Can't open /lib/udev/hotplug.functions'

Both of these look like errors. The script in /lib/udev/usb_modeswitch looks likes this:

#!/bin/sh
# part of usb_modeswitch 1.1.6
device_in()
{
if [ ! -e /etc/usb_modeswitch.d/$1 ]; then
return 0
fi
while read line
do
if [ $(expr "$line" : "$2:$3") != 0 ]; then
return 1
fi
done </etc/usb_modeswitch.d/$1
if [ $(expr "$line" : "$2:$3") != 0 ]; then
return 1
fi
return 0
}

p_id=$4
if [ -z $p_id ]; then
prod=$5
if [ -z $prod ]; then
prod=$3
fi
prod=${prod%/*}
v_id=0x${prod%/*}
v_id=$(printf %04x $(($v_id)) )
p_id=0x${prod#*/}
p_id=$(printf %04x $(($p_id)) )
else
v_id=$3
fi
case "$1" in
--driver-bind)
(
dir=$(ls -d /sys$2/ttyUSB* 2>/dev/null)
if [ ! -z "$dir" ]; then
exit 0
fi
set +e
device_in "bind_list" $v_id $p_id
if [ "$?" = "1" ]; then
id_attr="/sys/bus/usb-serial/drivers/option1/new_id"
if [ ! -e "$id_attr" ]; then
/sbin/modprobe option 2>/dev/null || true
fi
if [ -e "$id_attr" ]; then
echo "$v_id $p_id" > $id_attr
else
/sbin/modprobe -r usbserial
/sbin/modprobe usbserial vendor=0x$v_id product=0x$p_id
fi
fi
) &
exit 0
;;
--symlink-name)
device_in "link_list" $v_id $p_id
if [ "$?" = "1" ]; then
if [ -e "/usr/bin/tclsh" ]; then
exec /usr/bin/tclsh /usr/sbin/usb_modeswitch_dispatcher $1 $2 $v_id $p_id 2>/dev/null
fi
fi
exit 0
;;
esac
(
. /lib/udev/hotplug.functions
wait_for_file /usr/sbin/usb_modeswitch_dispatcher
exec /usr/sbin/usb_modeswitch_dispatcher "$@" 2>/dev/null &
) &

Is this script corrupted somehow?

Remember, at the moment, my udev rules file for modeswitch has been simplified to:

# Part of usb-modeswitch-data, version 20101223
#
# This file is intended for USB_ModeSwitch version >= 1.1.2
# but will not break anything if used with versions >= 1.0.3
#
ACTION!="add", GOTO="modeswitch_rules_end"

# This adds a symlink "gsmmodem[n]" to ttyUSB ports with interrupt transfer;
# will work only with wrapper from 1.1.4 and above (otherwise ignored)
#HOPPY KERNEL=="ttyUSB*", ATTRS{bNumConfigurations}=="*", PROGRAM="usb_modeswitch --symlink-name %p %s{idVendor} %s{idProduct} %E{PRODUCT}", SYMLINK="%c"

SUBSYSTEM!="usb", GOTO="modeswitch_rules_end"

# This adds the device ID to the "option" driver after a warm boot
# in cases when the device is yet unknown to the driver
#HOPPY ATTR{bInterfaceClass}=="ff", ATTR{bInterfaceNumber}=="00", ATTRS{bNumConfigurations}=="*", RUN+="usb_modeswitch --driver-bind %p %s{idVendor} %s{idProduct} %E{PRODUCT}"

# Most known install partitions are on interface 0, one on 5, one on 9
#HOPPY ATTRS{bInterfaceNumber}!="0[059]", GOTO="modeswitch_rules_end"

# only storage class devices are handled; negative
# filtering here would exclude some quirky devices
#HOPPY ATTRS{bDeviceClass}=="08", GOTO="modeswitch_rules_begin"
#HOPPY ATTRS{bInterfaceClass}=="08", GOTO="modeswitch_rules_begin"
#HOPPY GOTO="modeswitch_rules_end"

LABEL="modeswitch_rules_begin"

# Huawei, newer modems
ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1446", RUN+="usb_modeswitch '%b/%k'"

LABEL="modeswitch_rules_end"

[Josh]

The errors you found can in fact prevent the automatic switching.

Unfortunately, almost every udev version seems to provide different parameters to RUN scripts. It's a mess.

The second error is preventing the switching and the first error is preventing the driver binding.

The second error is caused by a difference between Debian and Ubuntu. The latter does not use the library of hotplug functions anymore. The file "hotplug.functions" is just not there anymore.
To fix that one, use the original "usb_modeswitch.sh" script from my source package and rename it to "/lib/udev/usb_modeswitch", replacing the Debian version.

To get information about the first error, insert a diagnostic command before line 20 (the existing "p_id=$4"):

Code: Select all

echo "1: $1 - 2: $2 - 3: $3 - 4: $4 - 5: $5" >>/tmp/shelltest
p_id=$4
...

This will log the parameters given by udev in the "shelltest" file. The interesting set of parameters will be the one which includes "--driver-bind".

[hoppy]

I've replaced the wrapper script in /lib/udev/usb_modeswitch with the usb_modeswitch.sh version and everything now appears to work.

Windows: It just worked
Linux: It took several hours for this experienced software engineer to get it working.

Thanks for your help!

[Josh]

Windows: It just worked
Linux: It took several hours for this experienced software engineer to get it working.

Well, blame the manufacturers who readily provide support for Windows, but choose to rely on unpaid enthusiasts for Linux support.

The notable exceptions being Sierra and Huawei who are providing Linux software on their recent sticks.