Automatic Activation, Hotplug and UDEV, Configuration
-
doktor5000
- Posts: 1
- Joined: 17 Mar 2012, 18:50
-
Contact:
Post
by doktor5000 » 17 Mar 2012, 19:36
Hi,
maybe i've got an understanding problem, after reading
http://www.draisberghof.de/usb_modeswitch/#trouble
The first suspects are existing system rules for modems which handle things not quite correctly.
If you own a device with the unswitched ID of 05c6:1000, it may get a wrong switching command in older systems. There are four different types of switching devices, all with that same ID; in the big distributions they were all treated alike as a model from "Option" (the manufacturer) which is wrong in four out of five cases. There are even cell phones with that ID which wrongly get the same treatment when connected to an USB port.
[...]
Annother notorious candidate is again 19d2:2000. It may be switched O.K. by an existing rule, but there is no driver loading if your model is new and its ID is not yet added to the "option" module. Disable the rule running "eject" and the ID will be handled by usb_modeswitch.
it seems there are many devices sharing the exact same ID here, I am not sure there is any reliable way to identify which modeswitch command to send.
Can you please explain to me how this happens?
-
Josh
- Site Admin
- Posts: 6593
- Joined: 03 Nov 2007, 00:30
Post
by Josh » 18 Mar 2012, 00:34
There are attributes in the firmware that can identify a device / maker / fw version even if the USB ID is re-used. The usb_modeswitch binary program does not know about these, but they are checked by the wrapping script which calls the binary with the correct config file.
See the README in the data package for specifics.
The first paragraph you quote refers to a kernel problem. There is mode switching code for 05c6:1000 in the "usb-storage" module from the time when usb_modeswitch was not generally known. Initially, it would only check for the ID and assume it was an "Option" modem - which led to problems with other devices.
I contributed a kernel patch to add a check just like in the usb_modeswitch package; it was accepted for kernel 2.6.32, so from then on that problem was gone. It may come up with older kernels, though.
Edit: The case for 19d2:2000 is different. Only devices with ZTE firmware are using it, and there is no need to differentiate because they can all be mode-switched with the same sequence.