Didier Raboud wrote:
Le mardi 5 mai 2009 20:12:07 Gildas Le Nadan, vous avez écrit :
Package: usb-modeswitch
Version: 0.9.7-1
Severity: important
Hi,
Hi Gildas,
first of all, thanks for having reported this very detailed bugreport. I very
much appreciate the time you have spent understanding my packaging stuff and
the way everything is imbricated.
You're welcome. I understand that the issue I raised might have deep
implications on the package, and I'm glad to find you open for discussion!
When I tried configuring my 3G ZTE/onda MF626 usb key, I had a hard time
trying to understand why after setting the right value in
/etc/usb_modeswitch.conf and having it work manually (using "sudo
usb_modeswitch"), I couldn't get it to work automagically through udev.
The reason was that there is 2 lines in /etc/usb_modeswitch.conf for the
ZTE MF626 and only the second one (which is supposed to be the
"fallback" solution) is present in the file usb_modeswitch.rules
generated by mkrules.py.
OK. I had hard time understanding this. The thing is that usb_modeswitch.conf
contains two "MessageContent" lines for the same set of configuration values.
########################################################
# ZTE MF628+ (tested version from Telia / Sweden)
# ZTE MF626
#
# Contributor: Joakim Wennergren
;DefaultVendor= 0x19d2
;DefaultProduct= 0x2000
;TargetVendor= 0x19d2
;TargetProduct= 0x0031
;MessageEndpoint=0x01
;MessageContent="55534243123456782000000080000c85010101180101010101000000000000"
# if that command doesn't work, try the other ("eject")
;MessageContent="5553424312345678000000000000061b000000030000000000000000000000"
This situation is not supported my mkrules.py for now. Actually, it uses the
second line.
My first idea to correct this bug was to ask to modify mkrules.py so it
includes the 2 lines, but I think this is probably the wrong approach.
This could be done without too much trouble. Maybe the easiest for this would
rather be to patch the configuration file to have two complete entries.
Glad it was as difficult for you to understand the problem than it was
for me :) It probably means though that my mail wasn't too clear.
My understanding of the rational behind mkrules.py is that is allows to
create a udev.rules that automatically contains entries for all the
devices in the mainstream package.
That is at least what I intended to do.
But in the actual form, on top of the actual bug I presented above, this
approach means you may have to modify 2 files to get your device working
in both manual and auto mode. This could lead to further discrepancies
in the configuration and imho is error prone.
I agree. This situation where you have to update two different files is error
prone and probably not "future prone" either.
Also, unless I've failed to notice something, I think it is useless
since if you don't specify parameters in the udev rule, usb_modeswitch
will get the right values from /etc/usb_modeswitch.conf.
This will be true only if the admin configured its /etc/usb_modeswitch.conf.
Ok so I think there was definitely something that I overlooked there.
IIUC now:
1- the general case is where there is only one entry defining one
specific DefaultVendor:DefaultProduct pair. In that case, the entry is
reported with the correct parameters in /e/u/r.d/usb-modeswitch.rules
and is supposed to "Just Work".
2- if there is more than one entry for one DefaultVendor:DefaultProduct
pair, the first one found in /e/usb_modeswitch.conf is uncommented, the
other one are commented out.
Thus, I believe that it would be more elegant to have mkrules.py
generate a usb_modeswitch.rules file containing one line per
DefaultVendor:DefaultProduct pair, without any parameter to the
usb_modeswitch command.
Some facts as I understand them :
* Bad commands sent to some devices could potentially break them.
* Some DefaultVendor:DefaultProduct strings point to multiple devices with
different needs (different commands).
Hmm then the actual solution isn't problem proof either.
If one device break because of the string send to it, then we can break
it with at least the two following scenarii (corresponding to the 2
cases defined above):
1- there is only one entry for a said DefaultVendor:DefaultProduct in
/e/usb_modeswitch.conf but there exists a second device out there
(unknown to usb_modeswitch) with the same entry, and that device will
break if setup with the values correct for the only known device.
2- there are multiple entries for said DefaultVendor:DefaultProduct in
/e/usb_modeswitch.conf and the first one contain a parameter that will
break one or several devices with the same DefaultVendor:DefaultProduct.
I think the problem here lies with the vendors, as IIUC, there should be
a different VendorId:ProductId per device type.
Do you have a link concerning problems of devices that could break?
There can be several approaches here, depending on how frequent it is.
I guess we can disallow automatic switch when there is a doubt on the
device (good candidates are different devices types/models with the same
idVendor:idProduct pair).
Or maybe we can explicitely blacklist some devices known to break and
force manual configuration?
* Some users could have multiple dongles which different needs (different
commands).
By setting an automatic launch of usb-modeswitch without options for each and
every possible device listed by upstream as "potentially working",
usb-modeswitch will be run with the options configured by the admin for each
device, potentially breaking your havoc.
I see some ways out :
(1) Implement your solution "no specifics in /e/u/r.d/usb-modeswitch.rules"
* Needs administrator configuration
I think administrator configuration is hard to avoid for devices where
DefaultVendor:DefaultProduct is not specific to that device (i-e there
is more than one entry with that DefaultVendor:DefaultProduct in
/e/usb-modeswitch.conf).
* Pros:
+ No manual edition of /e/u/r.d/usb-modeswitch.rules needed
+ Configuration is done in one place /e/usb-modeswitch.rules
I guess you meant /e/usb-modeswitch.conf?
* Cons:
- Works for only one device per machine
- Launches usb-modeswitch with false commands for all other devices, with
potential hardware breaking
If I understand correctly, this is already the case in the actual
solution when there is more than one match for a specific value of
DefaultVendor:DefaultProduct. In that case, you will use the first entry
found in /e/usb-modeswitch.conf.
For instance for my ZTE MF626, the value used by default was the one
from ZTE MF620.
- Works correctly for machines that only get connected to one device of
the list _ever_.
Aha! something else I overlooked.
I though usb_modeswitch was able to parse /e/usb-modeswitch.conf and
find the entry there that would match the connected devices.
It seems that I was wrong: I've created a /e/usb-modeswitch.conf file
with 2 entries. It only works if my device matches the first entry. Ok,
then the title for my bug report is obviously wrong and you did the
correct thing.
I think this is a major limitation of usb_modeswitch (it should be able
to read the entries for the _connected_ devices and run accordingly).
Now I understand why you did it that way in the
/e/u/r.d/usb-modeswitch.rules, and I think README.Debian should state
explicitely that /e/usb-modeswitch.conf can only contain _one_
uncommented entry or that it won't work as expected (unless the device
plugged is the first uncommented entry).
(2) Introduce a new binary "update-usb-modeswitch-rules"
This binary would create a /e/u/r.d/usb-modeswitch.rules
from /e/usb-modeswitch.conf in which the administrator could configure more
than one device.
* Pros
+ Works for multiple devices automagically (udev rule), according to admin
configuration
+ No potential hardware breaking (usb-modeswitch launched only for
configured devices)
+ No manual edition of /e/u/r.d/usb-modeswitch.rules needed
+ Configuration is done in one place /e/usb-modeswitch.rules
Again I guess you meant /e/usb-modeswitch.conf?
* Cons
- usb-modeswitch cannot be run without options if multiple devices are
defined in the .conf (but this should not be needed if autoconfiguration
works)
- new entry in NEWS.Debian with changes /again/ on how it works
- this binary needs to be run after configuration changes
(3) Completely change the way upstream works with its configuration
I suggested a more global solution in upstream's forum there:
http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=142
The idea is to get rid of this database as configuration but to settle it
down somewhere under /usr/ and then have a waaay simpler configuration file
which then only has identifiers.
I'm not sure I fully understand the solution. Do you mean that there
could be a way to automatically uniquely identify the plugged device and
to assign it to a specified id in the configuration DB, even if there is
more than one type of device for a single idVendor:idProduct pair?
The /etc/usb-modeswitch.conf could be splitted
in /etc/usb-modeswitch/manual.conf for manual runs
and /etc/usb-modeswitch/udev.conf which would be sourced by the above binary
to create a simpler /e/u/r.d/*.rules.
I haven't had any answer yet from upstream but I still think that this is
the way to go.
If you want to contact the upstream developper, have you tried either on
the forum sending a private message to Josh, or using the mail address
given in the source code?
Cheers,
Gildas Le Nadan
What do _you_ think ?
> Best regards,
>
> OdyX
>
Well it's a tough one once you include the problems I overlooked above.
If I take the following properties as desirable for the solution:
- work out of the box for most devices without any configuration, if
that's safe/if the user wants it that way
- allow for manual changes in one place only
I would say that ideally we would have:
- /etc/usb-modeswitch.conf would be the only place where the changes
occurs
- one should never have to modify the udev rules file, and it should
be as independant as possible from the configuration file
- if the user doesn't want the switch to happen automatically, there
is no udev rules installed
- if the idVendor:idProduct pair does not allow for identification of
a single device[1], automatic configuration for that
idVendor:idProduct pair should be disabled
- usb_modeswitch should identify the plugged usb devices and pick the
right values for them amongst the uncommented entries of
/etc/usb-modeswitch.conf
- usb_modeswitch should do nothing (or optionally prompt the user) if
there is more than one entry with the same id or no id for the
plugged devices
====IDEAL CASE====
usb_modeswitch is changed to support the behaviour described above.
In this case, if that's not supported by upstream already, use the
upstream usb-modeswitch.conf to create a /etc/usb-modeswitch.conf file
where entries are uncommented when the idVendor:idProduct pair is
unique. When there is more than one entry per idVendor:idProduct pair,
leave it commented (there should be a clear explanation in the
documentation about this).
Then, at installation time you can have debconf asking the user if it
wants automatic switch (udev support)
A) the user doesn't want udev support
don't create /e/u/r.d/usb-modeswitch.rules
B) the user wants udev support
- create /e/u/r.d/usb-modeswitch.rules with entries (ordered per
idVendor:idProduct) that call usb_modeswitch without
parameters for each known device:
----8<----
SUBSYSTEM=="usb", SYSFS{idVendor}==\
"indivConfig['DefaultVendor']", \
SYSFS{idProduct}=="indivConfig['Product']", \
RUN+="/usr/sbin/usb_modeswitch"
----8<----
/e/u/r.d/usb-modeswitch.rules should be regenerated at upgrade
time (to support new hardware).
====ADAPTATION TO ACTUAL CASE====
It would be best if this could be supported in the upstream
usb_modeswitch, but in the meantime you can maybe use a work-around in
the form of a wrapper that fetches the correct entries and feeds them to
usb_modeswitch.
(lets call it for instance udev_usb_modeswitch)
The entries in /e/u/r.d/usb-modeswitch.rules (created if user wants udev
support and ordered per idVendor:idProduct as in the ideal case) could
then look like:
----8<----
SUBSYSTEM=="usb", SYSFS{idVendor}==\
"indivConfig['DefaultVendor']", SYSFS{idProduct}==\
"indivConfig['Product']", RUN+="/usr/sbin/udev_usb_modeswitch \
indivConfig['DefaultVendor']:indivConfig['Product']"
----8<----
In this example udev_usb_modeswitch will take idVendor:idProduct as a
parameter and look for matching entries in its configuration file with
the same logic (pick the right values for idVendor:idProduct amongst the
uncommented entries of /etc/usb-modeswitch.conf, do nothing if there is
more than one matching entry, optionally complain in the logs)
The problem there is: do we want to have udev_usb_modeswitch using
/etc/usb-modeswitch.conf since it will cause problems to the manual
usage of usb_modeswitch?
Maybe then you can even retain the configuration files split that you
offered above (/etc/usb-modeswitch/manual.conf and
/etc/usb-modeswitch/udev.conf [2]), even though it would add complexity
to the overall solution.
/etc/usb-modeswitch/udev.conf could be constructed the same way as
/etc/usb-modeswitch.conf in the "ideal case":
- entries are uncommented when the idVendor:idProduct pair is unique
- entries are commented when there is more than one entry per
idVendor:idProduct pair, and there should be a clear explanation in the
documentation
- optionally, order entries per idVendor:idProduct
/etc/usb-modeswitch/manual.conf would contain commented out entries as
well as a header as follow:
----8<----
# /etc/usb-modeswitch/manual.conf
# This file is only needed if you have only one device and want to run
# usb_modeswitch manually, as usb_modeswitch only consider the first
# uncommented entry in its configuration file.
#
# In all other situations (if you have more than one device, if you want
# it to be automatically recognised and switched), please see
# /etc/usb-modeswitch/udev.conf
...
----8<----
Hope this helps.
Cheers,
Gildas
--
[1] this become moot abviously if you can uniquely identify a device,
but since I'm not sure that was the point of your configuration database
proposition, I'll be conservative here
[2] I'm not sure changing the names/path in the program for
/etc/usb-modeswitch.conf is a good idea, maybe we can call them
/etc/usb-modeswitch.conf and /etc/usb-modeswitch.udev (unless this is a
package policy requirement to have a directory).
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
