I've pinned down the origin of the bug: the information being provided
by udev to usb_modeswitch is not what usb_modeswitch is expecting. If
my understanding of the udev documentation is correct, then there must
be a bug in udev that is causing it to perform its %b substitution
incorrectly. Only an examination of the udev code can reveal why this
is happening.
Recall that the line in /lib/udev/rules.d/40-usb_modeswitch.rules that
gets matched for the K3520-Z is
ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="2000", RUN+="usb_modeswitch
'%b/%k'"
The udev documentation states:
$id, %b
The name of the device matched while searching the devpath upwards
for SUBSYSTEMS, KERNELS, DRIVERS and ATTRS.
Thus for the above rule %b ought to be the name of the parent device for
which idVendor is 19d2 and idProduct is 2000.
>From an examination of the contents of /sys/bus/usb/devices I have been
able to establish that the idVendor and idProduct files are in
/sys/bus/usb/devices/7-1 so 7-1 is the device for which idVendor and
idProduct matched. If, however, you look back at the debug output from
usb_modeswitch you will see the following:
Raw args from udev: 7-1:1.0/7-1:1.0
i.e. udev has told usb_modeswitch that 7-1:1.0 was the device for which
idVendor and idProduct matched. This misdirects usb_modeswitch into
trying to read device data from /sys/bus/usb/devices/7-1:1.0 and as that
directory does not contain idVendor and idProduct files, usb_modeswitch
is unable to identify the vendor and product with the result that it
can't work out how to switch the dongle's mode.
By once again renaming the kernel module usb-storage.ko out of the way
to prevent it automatically switching the K3770's mode, I have been able
to do the same analysis for the interaction between udev and
usb_modeswitch for that dongle.
The line in /lib/udev/rules.d/40-usb_modeswitch.rules that gets matched
for the K3770 is
ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="14d1", RUN+="usb_modeswitch
'%b/%k'"
so %b ought to be the name of the parent device for which idVendor is
12d1 and idProduct is 14d1. From an examination of the contents of
/sys/bus/usb/devices it is evident that the idVendor and idProduct files
are in /sys/bus/usb/devices/2-4 so 2-4 is the device for which idVendor
and idProduct match. In this instance the debug output from
usb_modeswitch starts
Raw args from udev: /2-4:1.0
Bus ID for device not given by udev.
Trying to determine it from kernel name (2-4:1.0) ...
Using top device dir /sys/bus/usb/devices/2-4
Once again udev has failed to pass the correct name of the device for
which idVendor and idProduct matched, but this time it has passed a null
value rather than an incorrect one. Fortuitously usb_modeswitch seems
to have code to cover this error, correctly deduces that the device
directory to use is 2-4, and hence is able to read the idVendor and
idProduct details successfully such that it can determine what steps are
necessary to switch the dongle's mode.
And that's my last word on the subject (other than to answer my own
question in the previous comment: I was indeed being naïve) for at least
a month. If no one has shown any interest in this bug by the time I get
back from holiday, I might try taking a look at the udev code (if I can
find it) to see if I can see what's going wrong there, always assuming
that it's written in a programming language that I understand.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1175093
Title:
K3520-Z mode not switched automatically
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1175093/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
