Bug#864604: usb-modeswitch: USB 3G modem is detected twice as "USB Mass Storage"
Am 11.06.2017 um 14:44 schrieb Teemu Likonen:
Extra info: If I run manually
modprobe usbserial vendor=0x1c9e product=0x9801
the 3G modem starts working.
This is a clear indication that usb_modeswitch is working as intended. There
is nothing it can change in that respect, the modem mode is reached.
It is in fact standard behaviour of a USB modem to provide either only its
MicroSD slot or both the slot and the install storage AFTER the mode switch,
in addition to the modem ports. So your's is not behaving unusually at all.
It looks like your modem's USB product ID is not yet included in the modem
driver ("option.c") in kernel version 4.9.0 (and indeed not in any more recent
version).
Previous usb_modeswitch versions took care of loading the driver 'manually'
when it didn't bind so you probably were not aware of that issue.
If you had had a look into the system log you would have seen this:
usb_modeswitch: add device ID 1c9e:9801 to driver "option"
usb_modeswitch: please report the device ID to the Linux USB developers!
You are not to blame of course - why should you look if everything worked? :-)
Bottom line:
The product ID 0x9801 needs to be added to the serial driver of the kernel.
For a quick fix you can do what usb_modeswitch did previously:
# modprobe -v option
# echo "1c9e 9801" > /sys/bus/usb-serial/drivers/option1/new_id
You can put this into a script and let it be called by udev automatically if
your modem is plugged. Put this below the first "ACTION" line in
/lib/udev/rules.d/40-usb_modeswitch.rules:
ATTR{idVendor}=="1c9e", ATTR{idProduct}=="9801", RUN+="/path/to/your/script"
Good luck,
Josua Dietze
Bug#812842: EnableLogging=1 doesn't have any effect
Am 27.01.2016 um 06:47 schrieb Jon Forsberg: This is how I invoke it: usb_modeswitch --default-vendor=0x12d1 --default-product=0x1446 -J -Q There is a bit of a misunderstanding there. The log is created during the automatic invocation of usb_modeswitch, when the wrapper (usb_modeswitch_dispatcher) is triggered by the insertion of a modem. For extended output during a manual run, add the -W parameter and remove the -Q parameter. Note that a bug has been found in the wrapper only recently which prevented logging of early problems, e.g. when the parameters passed to the wrapper are not useable and it therefore exits. This bug has been fixed in usb_modeswitch 2.3.0. There is a description in the discussion of bug report #805512 (see message #40): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805512 Best regards, Josh
Bug#805512: usb-modeswitch-data: Huawei 12d1:1446 does not switch due to bad udev rule
I have just released upstream version 2.3.0 of usb_modeswitch and version 20160112 of the data package. The bug with the missing log is fixed, as well as a potentially disruptive other bug in the wrapper (see http://draisberghof.de/usb_modeswitch/bb/viewtopic.php?p=16240 ). However, I have not been able to replicate bug #805512 that Blake Miner describes. Unfortunately, there is no way to move forward with this bug until I see the usb_modeswitch log with the raw parameter data transmitted by the systemd instance. Best regards, Josh
Bug#805512: usb-modeswitch-data: Huawei 12d1:1446 does not switch due to bad udev rule
Am 09.01.2016 um 00:14 schrieb Blake Miner: Honestly, I did try the whole usbmodeswitch logging thing to no avail There is only the one global switch in /etc/usb_modeswitch.conf - if that did not work, then it's very likely that the dispatcher is never run. I'll have a closer look at /lib/udev/usb_modeswitch. There may also be systemd involved, as I have stated before. Best regards, Josh
Bug#805512: usb-modeswitch-data: Huawei 12d1:1446 does not switch due to bad udev rule
Am 09.01.2016 um 00:14 schrieb Blake Miner: Honestly, I did try the whole usbmodeswitch logging thing to no avail I have found a stupid bug in the dispatcher which prevented early logging ... Edit the dispatcher script "/sbin/usb_modeswitch_dispatcher" (or "usb_modeswitch.tcl" in the source). Change line #731 from set $flags(logwrite) 1 to set flags(logwrite) 1 Now you should get a (short) log, showing at least the input parameter the dispatcher receives. Best regards, Josh
Bug#805512: usb-modeswitch-data: Huawei 12d1:1446 does not switch due to bad udev rule
Am 08.01.2016 um 21:25 schrieb Blake Miner: Bump. Any another thoughts on this bug? It's hard to tell if this is a usb-modeswitch bug (i.e. a problem with usb_modeswitch_dispatcher) or if this is a problem with the udev rule itself (a usb-modeswitch-data bug). Have you tried to enable usb_modeswitch's logging? If the rules are at least triggering and starting the dispatcher, there should be a log being created. /lib/udev/usb_modeswitch '2-1/2-1:1.0' does not work. /lib/udev/usb_modeswitch '/2-1' works just fine. The log should give more hints. Regards, Josh
Bug#805512: usb-modeswitch-data: Huawei 12d1:1446 does not switch due to bad udev rule
Am 19.11.2015 um 01:00 schrieb Blake Miner:
The catch-all udev rule does not work:
# Generic entry for all Huawei devices
ATTRS{idVendor}=="12d1", ATTR{bInterfaceNumber}=="00", ATTR{bInterfaceClass}=="08",
RUN+="usb_modeswitch '%b/%k'"
Thanks for the report. Upstream dev here.
This has been a puzzle for some time now. Most people don't have any problems
with this rule, but there are occasional hiccups like your's.
There is an educated guess that it's not the rule itself that is to blame. It's
very likely that the installed systemd version affects the respective outcome.
The problem is related to the creation of "instance units" for systemd.
USB_ModeSwitch requires this as there are possibly several instances started in parallel
(if there is more than one device connected which needs a mode switch).
These instances are defined by the *filename*, meaning that the template unit file
"usb_modeswitch@.service" will be instantiated as
"usb_modeswitch@.service".
Originally, the unchanged parameter from the RUN directive was used to name the instance.
At the time of testing, systemd translated the "/" character transparently.
However, there seems to have been a change so that re-translation did not work as before,
and subsequently the dispatcher script failed to recognize the parameter when the
instance name was passed on by the unit.
In usb-modeswitch 2.2.2, the parameter format was altered: "/" is replaced by
"_" *before* the systemd service unit is started. The dispatcher was modified accordingly.
I'm not sure if a version update is possible for Debian. Anyway, here is a
little patch that you can try (after restoring the 'catch-all' rule to its
original form). The patch is against 2.2.1 in the upstream version but should
be easy to apply to the Debian source manually.
Best regards,
Josh
diff -u u1/usb_modeswitch.sh u2/usb_modeswitch.sh
--- u1/usb_modeswitch.sh 2015-01-14 21:14:51.0 +0100
+++ u2/usb_modeswitch.sh 2015-11-19 10:09:47.128165935 +0100
@@ -74,6 +74,9 @@
;;
esac
exec 1<&- 2<&- 5<&- 7<&-
+IFS='/' read -r p1 p2 <
Bug#803603: usb-modeswitch-data: please make the build reproducible
Thanks for the hint! I have applied the patch to the new upstream version of the data package (20151101), available as of now; I was in the process of releasing it when you filed the bug. Great timing! Best regards, Josh
Bug#791677: usb-modeswitch: Doesn't work when called directly from systemd-udev(?), without any backend like modemmanager or so.
Am 07.07.2015 um 16:29 schrieb Martin Kebert: Package: usb-modeswitch Version: 2.2.0+repack0-2 Severity: normal Hi, I'm not sure about $SUBJ accuracy, but thing is that /usr/sbin/usb_modemswitch_dispatcher is called with wrong arguments when it is called without any other helper. Thanks for the report! However, it's possible that the latest releases (2.2.2 and 2.2.3, now in 'unstable') already overcome that problem. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787842 The problem is in the parameter hand-over to systemd unit templates, which works by appending the filename with those parameters. Consequently, slash characters are not possible and will be escaped to dashes. When 'un-escaped', *original* dashes are converted to slashes as well - which is obviously bad in this case. Anyway, the slash in the usb_modeswitch parameter is replaced with '_' now before being handed to systemd, and no more escaping is done. Odyx, if you want I can cobble together a patch to back-port the fix to 2.2.0. Regards, Josua Dietze (usb_modemswitch upstream) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786825: usb-modeswitch: Interferes with mass storage mode of HuaWei Y300
My previous suggestion was erroneous as it disables the rule entirely. The
attribute for iManufacturer has a different name in the sysfs tree, so the
rule never matches.
This is the corrected rule:
ATTRS{idVendor}==12d1, ATTRS{manufacturer}!=Android,
ATTR{bInterfaceNumber}==00, ATTR{bInterfaceClass}==08,
RUN+=usb_modeswitch '%b/%k'
The correction is included with the latest upstream release of the data
package, version 20150627.
Regards,
Josua Dietze
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787842: usb-modeswitch: Huawei e3131 not recognised
I have now decided to circumvent the escape issue with systemd alltogether.
In the next upstream release, the slash character in the parameter for the
usb_modeswitch systemd unit template is replaced with a less offending
character ('_').
The parameter expansion inside the unit file is changed from %I to %i, so
there will be no escaping at all.
I'm confident that this will solve the problem with your modem.
Best regards,
Josua Dietze
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787842: usb-modeswitch: Huawei e3131 not recognised
Am 06.06.2015 um 19:22 schrieb John Hedges: This patch might be more thorough: Thanks for the fix, and sorry for the late reply (I was on vacation). Would you be so kind and provide the RAW input that you get from systemd on your system with that modem? There should be a line close to the top in usb_modeswitch's log starting with Raw args from udev: Thanks again! As soon as I have double-checked that raw argument, I'll incorporate your fix in the coming release 2.2.2. Best regards, Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786825: Fwd: Bug#786825: usb-modeswitch: Interferes with mass storage mode of HuaWei Y300
Weitergeleitete Nachricht Von: Hugh Pumphrey hugh.pumph...@ed.ac.uk OK, here it is Bus 001 Device 007: ID 12d1:1037 Huawei Technologies Co., Ltd. Ideos Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x12d1 Huawei Technologies Co., Ltd. idProduct 0x1037 Ideos bcdDevice2.33 iManufacturer 2 Android iProduct3 Android iSerial 4 D46E5C22785E bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 1 Mass Storage Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) root@corona:~# BTW, you don't have to uninstall usb_modeswitch. Just edit /etc/usb_modeswitch.conf and set DisableSwitching to 1. Many thanks for the tip. Best wishes Hugh Pumphrey -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786825: usb-modeswitch: Interferes with mass storage mode of HuaWei Y300
Thanks, Hugh Pumphrey!
With this USB attribute listing we can try to exclude Android phones from the
mode-switching trigger rule.
You can help once more if you re-install usb_modeswitch (and its data package)
and then modify a line in the file
/lib/udev/rules.d/40-usb_modeswitch.rules
At line 24, there is the trigger that I referred to.
Change it to this:
ATTRS{idVendor}==12d1, ATTRS{iManufacturer}!=Android,
ATTR{bInterfaceNumber}==00, ATTR{bInterfaceClass}==08,
RUN+=usb_modeswitch '%b/%k'
As you can see, the only thing added to the existing line is this condition:
ATTRS{iManufacturer}!=Android
Hopefully this will filter out all devices which have the entry Android in
their iManufacturer attribute. So to test this you would have to enable
mode-switching, connect your phone, and in the best case nothing will happen.
Remember to direct your answer also to the bug address. It's best to simply
hit Reply to all.
Regards,
Josua Dietze
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786825: usb-modeswitch: Interferes with mass storage mode of HuaWei Y300
Am 25.05.2015 um 22:46 schrieb Hugh Pumphrey: When I upgraded to jessie, this all stopped working. (Simpler USB storage devices, e.g. cheap thumb drives, carried on working as normal.) Poking about the internet, I became suspicious of usb-modeswitch and tried un-installing it --- fortunately, nothing seemed to depend on it. My phone's USB mass storage immediately began to work as it had in wheezy. There has been indeed a change in usb_modeswitch to catch all Huawei *modems* with one udev rule. Now it looks like we need to exclude smartphones from that rule. For this we need some more information. Would you be so kind to run the following command on the command line while the phone is connected in storage mode? lsusb -v -d 12d1:your-product-id (You get the full USB ID of your phone by running just lsusb) If this succeeded, reply here with the full output of the command. Thanks! BTW, you don't have to uninstall usb_modeswitch. Just edit /etc/usb_modeswitch.conf and set DisableSwitching to 1. Regards, Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779919: usb-modeswitch: IOMMU in BIOS not handled properly
Am 06.03.2015 um 13:35 schrieb William Melgaard: Although the USB-2 mouse and keyboard are dealt with effectively with IOMMU enabled, there are ~550 lines of page fault reported by dmesg at bootup. Further investigaiton finds that failure to access the northbridge (AMD 970 chip) USB-3 support is the cause of the page faults. usb_modeswitch is not involved in the standard boot process unless a USB device with multiple modes is attached, mainly 3G/4G modem or Wifi sticks. If this is not the case with your system, then I think your problem is rather related to the Linux kernel. Regards, Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698413: usb-modeswitch-data: Huawei e3276 no longer switched
Am 02.08.2014 19:43, schrieb Didier 'OdyX' Raboud: Josua: what do you think could be done there? Uh, sorry, this was not on my radar anymore ... I just checked version 1.2.5 with two cascaded USB hubs and got the same problem as Stefano with a mutilated device path. It seems I have incorporated the fix in 1.2.6 which works just fine with the hub chain. To my partial exoneration I can say that the Changelog states: fix for error with cascaded hubs in dispatcher script So I look forward to a mild verdict, even if I had failed to close this bug properly 8-] I'd appreciate if you would this as soon as it suits you ... Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754348: Info received (Bug#754348: Rule test)
For completeness' sake, here is the excerpt from the rules file. Only the
relevant lines are included.
/lib/udev/rules.d/40-usb_modeswitch.rules
ACTION!=add|change, GOTO=modeswitch_rules_end
[...]
# Don't continue on change event, prevent trigger by changed configuration
ACTION!=add, GOTO=modeswitch_rules_end
# Generic entry for all Huawei devices
ATTRS{idVendor}==12d1, ATTR{bInterfaceNumber}==00,
ATTR{bInterfaceClass}==08, RUN+=usb_modeswitch '%b/%k'
[...]
LABEL=modeswitch_rules_end
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754348: [usb-modeswitch] The catch-all udev rule for Huawei devices does not work for my E1800 stick)
O.K., here is a suggestion about how to test the new Huawei udev rule.
Obviously the new versions of usb-modeswitch and usb_modeswitch-data should be
installed.
1. Disable mode-switching (edit /etc/usb_modeswitch.conf) just to be on the
safe side, run this command:
udevadm monitor
and plug your Huawei modem in.
2. From the monitor output, pick the path to interface 0. In my setup, this was:
/devices/pci:00/:00:12.2/usb5/5-3/5-3:1.0. Note that your values
will be different.
This is the specific device that is supposed to trigger the mode-switch rule.
3. Run
udevadm info -a -p your-path-from above
You will get the full attribute tree that can be checked by a rule entry. In
my setup, it contained these lines which are relevant:
ATTR{bInterfaceClass}==08
...
ATTR{bInterfaceNumber}==00
...
ATTRS{idVendor}==12d1
If one of these is missing in your setup, there may be an issue with the
specific udevd version.
4. Run
udevadm test --action=add your-path-from above
This is a simulation and should clearly name usb_modeswitch as being run.
Josh
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754348: Rule test
Am 12.07.2014 21:22, schrieb Maciej Kotliński: I tested switching as you wrote. Thanks, Maciej. I can see no reason why the Huawei rule should not trigger. Odyx, can we somehow involve the udev maintainer(s)? For the record, my udev version is 208 (udevadm --version). Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754348: [usb-modeswitch] The catch-all udev rule for Huawei devices does not work for my E1800 stick
Hmm. The modem looks like it should. The udev rule should trigger when this interface is added. bInterfaceNumber0 ... bInterfaceClass 8 Mass Storage Last night, I tested all my six Huawei modems with the new catch-all rule - again. No problems of any kind. There is a command to simulate the trigger with the help of udevadm. Tonight, I'll figure out the right parameters and post the whole command line. Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754499: usb-modeswitch-data: Broken rule for Huawei E3272 (12d1:1f01)
Am 11.07.2014 21:23, schrieb Maciej Kotliński: My Huawei E3272 (12d1:1f01) does not get switched after plugging. Please join this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754348 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754348: [usb-modeswitch] The catch-all udev rule for Huawei devices does not work for my E1800 stick
Thanks for the report, Giacomo. Can you post one more information detail? With your stick *not* switched, run sudo lsusb -v -d 12d1:1446 E1800.lsusb and paste the content of the E1800.lsusb file to your reply. Josh (usb_modeswitch 'upstream') -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751271: usb-modeswitch: doesn't switch Huawei E3131s-2 on boot
Did the problem go away when you downgraded? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751271: usb-modeswitch: doesn't switch Huawei E3131s-2 on boot
Am 11.06.2014 19:44, schrieb Jakub Wilk: To be sure it works, I first tried with the old version of usb-modeswitch(-data). It turns out that logging during boot not only doesn't work, but it actually prevents switching. :\ O.K., there still should be a hint about usb_modeswitch running in the system log, at least with the older version. Can you spot it and then compare with what you see when the new version is installed? My gut tells me the problem is timing-related. The next step would be to unpack the E3131 configuration from the data package in /usr/share/usb_modeswitch and copy it to /etc/modeswitch.d where it can be modified to try out several things. For you it would be the config file named 12d1:14fe. Don't bother about the name in the description, model names are hardly ever consistent when it comes to mobile modems. Regards, Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751271: usb-modeswitch: doesn't switch Huawei E3131s-2 on boot
Am 11.06.2014 18:05, schrieb Jakub Wilk: After I upgraded usb-modeswitch (2.1.1+repack0-1 = 2.2.0+repack0-1) and usb-modeswitch-data (20140327-1 = 20140529-1), my Huawei E3131s-2 is no longer switched on boot: Can you try to get an usb_modeswitch log? I'm not sure if it works properly during boot, but it may be worth a try. Set EnableLogging = 1 in /etc/usb_modeswitch.conf and go to /var/log after booting with the stick. Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731016: Can't mount external USB HD Asus AN300
It's clear now that usb_modeswitch can't do anything here. Please reassign - my guess is that it's a kernel driver thing, either USB 3.0 host or usb-storage (or both).
Bug#731016: Can't mount external USB HD Asus AN300
Am 04.12.2013 15:07, schrieb Ben Hutchings: Le mercredi, 4 décembre 2013, 11.01:14 Josua Dietze a écrit : It's clear now that usb_modeswitch can't do anything here. I don't see that at all. There could be some magic file on the virtual CD-ROM that Windows already knows how to interpret. (I don't know what the point of that would be!) That is highly unlikely. After all, there are only two possibilities: 1. Windows accesses the main drive device in a generic (built-in) way. If this included some sort of 'magic' file, then that way of access would be known - if not documented - by now. It's not likely that the Asus drive would be the only device where this special generic access method applied. 2. A special software is used for access or at least for initialisation before using the main drive device. This has been ruled out by Ido's tests. usb_modeswitch helps with devices that change their complete layout after receiving a specific command. In most cases this involves a change of the USB product ID, but there is *always* a change in interface layout and classes. I can't see that with the Asus drive. The interfaces with their expected device class seem to be there from the moment of plug-in. That said, it would become clearer with a detailed lsusb listing. Some interface details are visible in the udev monitoring output from the original report, but not very concise. Ido, can you run the following terminal command with the drive connected? $ sudo lsusb -v -d 0b05:17b6 Then post the output in your reply, please. (As a side note, I noticed that long lines of text are not wrapped on the bug track page - is that intended?) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731016: Can't mount external USB HD Asus AN300
usb_modeswitch can only help if the device needs a special initialization before becoming useable in a standard way. The indication for this is that Windows will ask for driver installation when the disk is plugged in for the first time. If it works on Windows right away with no installation required at all, then the USB storage driver of Linux is the place to try fixes or work-arounds. Googling for this device brought up only cries for help w/ respect to Linux - so far, I could not find any indication of a successful connection. The official product page lists only OS X and Windows as supported systems. In case there IS a driver required on Windows, you might be able to catch the initial traffic between this driver and the device once the thing is re-plugged. In a second step, the initiating command(s) can possibly be 'replayed' in Linux. This is the usual way usb_modeswitch works. Note that if a special Windows driver is required for actually ACCESSING the disk (not just for initialization), then a new Linux driver may be required as well ... Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561251: mount: Bluebirds shows as /media/dvd when no disk is in reader!
Am 15.11.2013 15:51, schrieb Phillip Susi: This is a misfeature of the drive, not a bug in mount. You may be able to use usb-modeswitch to disable the feature, so I'll reassign the bug to there for now so that those familiar with it may be able to help. usb_modeswitch is limited to USB devices, and I understand this is a SATA device. However, when checking the link about the Windows fix (message #10), I found it was updated: EDIT: I have removed to the tool from this post because LG has posted an offical firmware update that removes the Bluebirds feature. I assume that would solve the problem. Regards, Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698284: usb-modeswitch-data: ttyUSB* rule should have SYMLINK+= not SYMLINK=
Am 10.06.2013 13:39, schrieb Didier 'OdyX' Raboud: Apparently you forgot to include this change in the new rules file (also in the gen_rules.tcl) apparently; was that intentional? Darn - of course not ... That's what you get for waiting too long between releases. I am about to issue annother bugfix release (20130610) for the data package. Thanks and best regards, Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698413: usb-modeswitch-data: Huawei e3276 no longer switched
Am 19.01.2013 10:30, schrieb Stefano Rivera: With 20121109-1 I get /var/log/usb_modeswitch_1-1.2 containing: | USB_ModeSwitch log from Sat Jan 19 11:25:40 SAST 2013 | | Raw args from udev: /1-1.2 | | Using global config file: /etc/usb_modeswitch.conf | Could not determine top device dir from udev values! Exiting You need usb-modeswitch 1.2.5 for the new udev rule flavour of data 20121109. I think I failed to stress that requirement - sorry! The head information in the rules file is obviously incorrect. Should read: # Use with USB_ModeSwitch = 1.2.5 ! Regards, Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698413: usb-modeswitch-data: Huawei e3276 no longer switched
Am 18.01.2013 10:01, schrieb Didier 'OdyX' Raboud: That's very weird as 20120815-2 and 20121109-1 have the exact same configuration file for 12d1:14fe : I was just about to write and point out that very same fact. Stefano, can you retrieve a mode-switching debug log? See /etc/usb_modeswitch.conf for the setting and some hints. Regards, Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698284: usb-modeswitch-data: ttyUSB* rule should have SYMLINK+= not SYMLINK=
Am 16.01.2013 10:57, schrieb Didier 'OdyX' Raboud:
Le mercredi, 16 janvier 2013 09.53:26, John Hedges a écrit :
Symlinks created by local rules for ttyUSB devices are lost because of the
following rule in /lib/udev/rules.d/40-usb_modeswitch.rules
KERNEL==ttyUSB*, ATTRS{bNumConfigurations}==*, PROGRAM=usb_modeswitch
--symlink-name %p %s{idVendor} %s{idProduct} %E{PRODUCT}, SYMLINK=%c
Chould it be changed to SYMLINK+=%c ?
As I don't have a definite opinion on that, let's see what upstream thinks.
Josh: what's your opinion ?
Yes, this definitely should be changed. There is no disadvantage.
I will do so in the next release, but that is not scheduled yet - so you might
want to correct this prior to my update.
Thanks everyone!
Josh
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686840: udev: Fails to mount SD storage cards in device with idVendor=0e8d, idProduct=0002
Fortunately (or not, depending on the point of view) I just had a direct report about this same problem. At the heart of the matter is the decision of the phone/firmware makers to re-use the USB ID of the MediaTek modems. Now we have to separate phones from modem sticks. The solution is to alter the config file name 0e8d:0002 to 0e8d:0002:uPr=MT in the usb_modeswitch data package. The known phones with the ID have iProduct attributes beginning with X, modems have MT. By changing the name, phones will be left alone entirely. This will of course be changed in the next upstream release of the data package; maybe Odyx can release a small fix in advance. Cheers, Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656063: Same crash with version 1.2.3+repack0-1
Am 31.01.2012 23:07, schrieb Frédéric MASSOT: I have the same bug with version 1.2.3+repack0-1 : Jan 31 22:27:04 lobon usb_modeswitch_dispatcher: *** glibc detected *** usb_modeswitch_dispatcher: free(): invalid next size (normal): 0x0966fff0 *** Can you enable logging in /etc/usb_modeswitch.conf and see how far the log goes? Thanks, Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657579: usb-modeswitch: usb_modeswitch_dispatcher Segmentation fault on armhf
Am 27.01.2012 08:46, schrieb Belousow Makc: Package: usb-modeswitch Version: 1.2.2+repack0-1 Severity: important Dear Maintainer, usb_modeswitch_dispatcher have Segmentation fault on Debian armhf: #1 0xb6eea8cc in _IO_vfprintf_internal (s=optimized out, format=optimized out, ap=...) at vfprintf.c:1620 I think this is the known bug 656688: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656688 Can you try the patched source pack provided there? Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656688: usb_modeswitch throws general protection errors to syslog
Am 24.01.2012 21:21, schrieb Kein Kommentar: this version works for me. Thank you. usb-modeswitch-1.2.2-1.tar.bz2 Thanks for the confirmation, everyone. I will do an upstream bugfix release which Odyx can just package as usual. Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656063: Test version with bug fixes
I have prepared a test version with fixes. You can uninstall the Debian package and install from source until a fixed deb is available. http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-1.2.2-1.tar.bz2 As a prerequisite for installation you need the libjim-dev package. In the source folder, run make install. For any new deb package, run make uninstall in the source folder before installing it. There will be no side effects. Note that this is a special source package tailored for Debian. I'm looking forward to hearing any reports. Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656688: usb-modeswitch: no ttyHS* devices
I have found an issue with the handling of the script when embedding
into the C code of dispatcher.c. I have introduced format commands
in two places that are using the %.. format description; this
interferes badly with the sprintf command.
The attached patch separates the sprintf operation from the rest of the
script code.
Unfortunately, I have run into bug #656063 afterwards, but that's
annother story.
Josua Dietze
diff -urN usb-modeswitch-1.2.2/dispatcher.c usb-modeswitch-1.2.2-1/dispatcher.c
--- usb-modeswitch-1.2.2/dispatcher.c 2012-01-19 01:01:50.0 +0100
+++ usb-modeswitch-1.2.2-1/dispatcher.c 2012-01-22 09:21:50.0 +0100
@@ -63,8 +63,9 @@
strncat(arglist,arg,MAX_ARGSIZE-1);
}
-char code[sizeof(RAW) + sizeof(arglist)];
- sprintf(code, RAW, arglist, argc-1);
+ char code[sizeof(RAW) + sizeof(arglist) + 28];
+ sprintf(code, set argv {%s}\nset argc %d\n, arglist, argc-1);
+ strncat(code, RAW, sizeof(RAW));
/* Create Jim instance */
interp = Jim_CreateInterp();
diff -urN usb-modeswitch-1.2.2/make_string.tcl
usb-modeswitch-1.2.2-1/make_string.tcl
--- usb-modeswitch-1.2.2/make_string.tcl2012-01-19 01:02:04.0
+0100
+++ usb-modeswitch-1.2.2-1/make_string.tcl 2012-01-22 09:22:06.0
+0100
@@ -28,4 +28,4 @@
}
}
close $f
-puts #define RAW \set argv {%s}\\nset argc %d\\n[join $sourcelines ]\
+puts #define RAW \[join $sourcelines ]\
Bug#656063: usb_modeswitch_dispatcher: free(): invalid next size
Am 15.01.2012 17:48, schrieb Frederic MASSOT:
I have several crash of usb_modeswitch_dispatcher ...
...
Jan 15 17:12:23 lobon usb_modeswitch_dispatcher: *** glibc detected
*** /usr/sbin/usb_modeswitch_ dispatcher: free(): invalid next size
(normal): 0x099c3340 ***
After several tests I have pinpointed a problem with seems to revolve
around setting the PATH environment variable from within the dispatcher
script. Any subsequent exec command resulted in a crash.
This happens only with the binary dispatcher and *only* in the
udev-triggered context. Running the binary dispatcher manually from the
command line will succeed as expected.
I have attached a patch for an immediate work-around.
Further research is neccessary though.
Josua Dietze
diff -urN usb-modeswitch-1.2.2/usb_modeswitch.tcl
usb-modeswitch-1.2.2-1/usb_modeswitch.tcl
--- usb-modeswitch-1.2.2/usb_modeswitch.tcl 2012-01-19 01:02:58.0
+0100
+++ usb-modeswitch-1.2.2-1/usb_modeswitch.tcl 2012-01-22 11:43:21.0
+0100
@@ -27,7 +27,7 @@
set flags(logging) 0
set flags(noswitching) 0
-set env(PATH) /bin:/sbin:/usr/bin:/usr/sbin
+#set env(PATH) /bin:/sbin:/usr/bin:/usr/sbin
# Execution starts at file bottom
@@ -230,7 +230,7 @@
# Now we are actually switching
if $flags(logging) {
Log Command to be run:\nusb_modeswitch -I -W -D -s 20
$configParam $busParam $devParam -v $usb(idVendor) -p $usb(idProduct) -f
\$configBuffer
- set report [exec usb_modeswitch -I -W -D -s 20
$configParam $busParam $devParam -v $usb(idVendor) -p $usb(idProduct) -f
$configBuffer 2@ stdout]
+ set report [exec /usr/sbin/usb_modeswitch -I -W -D -s
20 $configParam $busParam $devParam -v $usb(idVendor) -p $usb(idProduct) -f
$configBuffer 2@ stdout]
Log \nVerbose debug output of usb_modeswitch and
libusb follows
Log (Note that some USB errors are to be expected in
the process)
Log
@@ -238,7 +238,7 @@
Log
Log (end of usb_modeswitch output)\n
} else {
- set report [exec usb_modeswitch -I -Q -D -s 20
$configParam $busParam $devParam -v $usb(idVendor) -p $usb(idProduct) -f
$configBuffer 2@ stdout]
+ set report [exec /usr/sbin/usb_modeswitch -I -Q -D -s
20 $configParam $busParam $devParam -v $usb(idVendor) -p $usb(idProduct) -f
$configBuffer 2@ stdout]
}
break
} else {
Bug#656854: usb-modeswitch throws general protection error and umts modem is unusable
Am 22.01.2012 13:49, schrieb Joaquim Boura: after plug.in the usb device ( tried with different ones) no tty is found. An error message is thrown to /var/log/messages and the umts modem is unusable. This is the same issue as bug #656688. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656688 Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656248: closed by Didier Raboud o...@debian.org (Bug#656248: fixed in usb-modeswitch 1.2.2+repack0-1)
Am 22.01.2012 20:28, schrieb Ralf Jung: Unfortunately, this is not fixed: After upgrading from the package you built for me to the package from sid (I am using testing), I am getting this error in the syslog (and no mode switch is performed): [ 1366.406054] usb_modeswitch_[11070] general protection ip:7eff71e72038 sp:7fffca3fc790 error:0 in libc-2.13.so[7eff71e2e000+17a000] Downgrading back to 1.2.1+repack0-1+0fix656248~0 fixed the problem. This bug is known as #656688 so it is not necessary to re-open this one. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656688 Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656688: usb-modeswitch: no ttyHS* devices
Am 21.01.2012 08:39, schrieb Kein Kommentar: 1.2.2 doesn't work for me: [ 127.574239] usb_modeswitch_[3115] general protection ip:7f576f2b5038 sp:7fff2172c0a0 error:0 in libc-2.13.so[7f576f271000+17a000] Hmm, that's a real crash. I have yet to test that Debian package. Please stand by. Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656688: usb-modeswitch: no ttyHS* devices
Am 21.01.2012 00:03, schrieb Kein Kommentar: Version: 1.2.1+repack0-1+b1 with this version my Globetrotter HSUPA Modem (idVendor=0af0, idProduct=7011) has no /dev/ttyHS* devices. This is a device using the TargetClass parameter, so it is likely affected by the known bug described here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656248 Can you try the fixed version 1.2.2? It is up on http://packages.debian.org/sid/usb-modeswitch Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656248: HP LaserJet Professional P1102 not properly switched anymore (regression)
Odyx et al., upstream version 1.2.2 is available. Only changes against 1.2.1 are the bug fix for #656248 and a more detailed log output in case of target parameter mismatch. Cheers, Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656248: HP LaserJet Professional P1102 not properly switched anymore (regression)
Am 17.01.2012 20:26, schrieb Ralf Jung:
Looking for default devices ...
bus/device number matched
searching devices, found USB ID 03f0:002a
found matching vendor ID
found matching product ID
target class 07 not matching
No devices in default mode found. Nothing to do. Bye.
The problem is right there.
The change in the logic to support bus/device-focussed identification
has introduced a bug.
If you are able to change the source code (usb_modeswitch.c), try to
edit line 1541 from
if (mode == SEARCH_DEFAULT) {
to
if (mode == SEARCH_DEFAULT || mode == SEARCH_BUSDEV) {
This should improve things.
Thanks for the report!
Josh
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642216: I have the same problem with e173-u2 - worked around, by, unpacking config file from configPack.tar.gz
Am 03.11.2011 10:11, schrieb Wojtek Zabolotny: Josua Dietze wrote: Also, what happens if you put the unpacked file in /usr/share/usb_modeswitch (beside the package file) instead of /etc/usb_modeswitch.d ? Yes, unpacking into /usr/share/usb_modeswitch halped also. In that case, version 1.2.0 should solve the problem and make it possible to switch reliably at boot time with the *packed* config files. Regards, Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: Additional Information (+packaging jimtcl)
Am 17.10.2011 12:27, schrieb Didier Raboud: After a rapid look trough it, I noticed that you embed jimtcl 0.71; unfortunately, this fact somehow means that I will have to package jimtcl independently from usb-modeswitch, patch it out from the source tarball we release and patch usb-modeswitch's buildsystem to use the now external jimtcl. I acted under the impression that everybody (well, all kinds of maintainers) was complaining about the Tcl package dependency. So I tried to get rid of it. If they don't mind or if they choose Jim, so be it. If you do make install-light you get the exact configuration as before, depending on an installation of Tcl or Jim. You don't have to patch out anything. If you wish we can discuss the default (make all) which now selects the embedded variant. Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: Additional Information
Am 14.10.2011 23:14, schrieb Christian Kastner: This works for me, too! Specifically, extracting the config for 12d1:1446 (my USB modem's ID) and placing it in /etc/usb_modeswitch.d. Aah. That restores my faith in determinism :-) But: if you need an alpha/beta tester for the upcoming 1.2.0 packages, just let me know and I'd be happy to test them! Taking your word for it - here we are: http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-1.2.0.tar.bz2 Read the README about the two install options. I'd be grateful if you could test both. Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: Additional Information
Am 15.10.2011 08:29, schrieb Josua Dietze: Taking your word for it - here we are: Sorry, wrong link, use this one: http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-1.2.0beta.tar.bz2 Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: Additional Information
Le mardi, 11 octobre 2011 19.07:27, san...@0x7f.nl a écrit : I recently ran across the same issue (though be it with a different version of usb-modeswitch) and since this one wasn't closed I thought I'd report my findings. I'm not sure your situation is the same as that of the original reporter. Christian Kastner found no trace at all of usb_modeswitch running during boot. Anyway, I'm already working on a modification of the binary program to enable reading a config file content from stdin. Once this works, it will eliminate the need for writing *anything* to the filesystem. Stand by for version 1.2.0 ... Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642216: I have the same problem with e173-u2 - worked around by, unpacking config file from configPack.tar.gz
Am 20.09.2011 15:18, schrieb Wojtek Zabolotny: I was able to cure this situation by manual extraction of the proper configuration file: 12d1:1446 from configPack.tar.gz into /etc/usb_modeswitch.d Did it work with version 1.1.4 ? That's what bug #629371 is about. Also, what happens if you put the unpacked file in /usr/share/usb_modeswitch (beside the package file) instead of /etc/usb_modeswitch.d ? Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: usb-modeswitch: Devices no longer detected when plugged in at boot-time
Am 17.08.2011 01:10, schrieb Christian Kastner: I did not yet have time to run the full battery of tests (eg [0]), but will do so as soon as I can. I am almost out of clues about what else is there to test. I'll try further to evoke the problem on my systems somehow. So far, this has failed. Thanks for your patience and perseverance... Likewise ... Josh -- Man is the only creature on earth enabled to take a warm meal while flying. Loriot -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637972: usb-modeswitch: switching functionality works only once after a fresh reboot with usb-stick XS Stick W14
Am 16.08.2011 08:01, schrieb Detlev Brodowski: The package does not switch my usb-stick XS Stick W14 into the needed mode after I have detached and reattached the usb-stick, till the next reboot. Can you enable logging in /etc/usb_modeswitch.conf and attach the log from a failure to your reply? You will find it in /var/log a while after you re-plugged the stick. Thanks, Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637972: usb-modeswitch: switching functionality works only once after a fresh reboot with usb-stick XS Stick W14
Am 16.08.2011 14:41, schrieb Detlev Brodowski: I have activated logging. Thanks for the logs. They confirmed the bug very nicely. I've done some testing and found one system where the same error was occurring. For a fix, edit /usr/sbin/usb_modeswitch_dispatcher and look for line 244. It says # after 500; now just remove the comment sign # and save. See if you get rid of the problem afterwards. Thanks Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637972: usb-modeswitch: switching functionality works only once after a fresh reboot with usb-stick XS Stick W14
Am 16.08.2011 20:47, schrieb Detlev Brodowski: It works. :) Odyx, can you release the fix as a patched-up version? I would not like to do a full release if I don't have to. Thanks, Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: usb-modeswitch: Devices no longer detected when plugged in at boot-time
Am 13.08.2011 10:03, schrieb Josua Dietze: The main issue was that udev did not run usb_modeswitch _at all_ during boot on the router. That may shift the focus to the udev rules file, which is part of the data package. Oddly enough, I received a report by mail from someone at AltLinux. He encountered a boot-n-switch problem as well. His analysis is quite interesting (quoted): The reason for that is that the kernel emits only 'change' events for the devices it finds already plugged-in when 'udevadm trigger' is called on the udev service start. However, only 'add' events are processed by the modeswitch udev rule script. The udev version involved was 172 which is fairly new. The fix should be easy - let the rules be evaluated not only for an add event but also for a change event. To put it in a nutshell: in /lib/udev/rules.d/40-usb_modeswitch.rules change this line ACTION!=add, GOTO=modeswitch_rules_end to this: ACTION!=add|change, GOTO=modeswitch_rules_end Let's see if there will be any change (ahaha). Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: usb-modeswitch: Devices no longer detected when plugged in at boot-time
Am 11.08.2011 00:34, schrieb Christian Kastner:
Strange thing: on my netbook the problem hasn't changed, but on my
desktop PC switching occurs with versions 1.1.4 to 1.1.9 (as confirmed
by lsusb and dmesg output), but the /dev/gsmmodem symlink does not get
set up in versions 1.1.7 and above.
So what you are saying that the main problem (no mode switch at boot) is now
limited to your router, right?
Regarding the symlink, the logic has changed somewhat in 1.1.7; to avoid
treating unrelated devices, a list of known USB IDs is checked before acting.
This list is appended if you switch your device for the first time by plugging
in. You will get the symlink from every following mode switch, but not on that
first encounter.
So, to test this feature during a boot process, you would in advance have to 1.
install, 2. plug in, 3. reboot (with or without a previous re-plug cycle).
The list of known devices is being deleted when uninstalling, so you have the
same situation after each version testing. See /var/lib/usb_modeswitch/link_list
if you want to check it out.
Resuming the earlier exchange, the error that you saw in the udev debug log
should be gone with version 1.1.9 ('arithmetic expression: expecting EOF:
0x'). Also, the shell script is not likely to be the culprit when it is not
even being called during boot.
The main issue was that udev did not run usb_modeswitch _at all_ during boot on
the router. That may shift the focus to the udev rules file, which is part of
the data package.
Can you tell us which usb-modeswitch-data version is currently installed on your
gateway router?
And did you install a new data package on your desktop machine at some point?
Regards,
Josh
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634916: usb-modeswitch: seems to have no effect on Huawei E169
Am 09.08.2011 15:47, schrieb Didier Raboud: I would like to have Josua's (upstream author) input on this bug. I think doing nothing but closing as such would be OKay, but his take on that would be valuable. Everything seems fine ... Just one thing kept bothering me: kernel: [48972.216084] usb 6-1: USB disconnect, device number 2 kernel: [48972.952054] usb 6-1: new full speed USB device number 3 using uhci_hcd This is exactly the behaviour you see during a mode switch. And now I remembered - there is a switching routine for the early Huawei modems built into the usb-storage driver! I have all but forgotten; at the time, there was a discussion about adding further mode switching code to the kernel. The USB developers decided against that (what CAN be done in userspace, SHOULD be done in userspace) but at the time there was already code added for some few devices. This has stayed in the kernel for compatibility reasons. In the kernel's usb-storage folder, there is the file unusual_devs.h which has this entry: UNUSUAL_DEV( 0x12d1, 0x1001, 0x, 0x, HUAWEI MOBILE, Mass Storage, USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init, 0), The mode-switching function is in usb_stor_huawei_e220_init, obviously. It does exactly what usb_modeswitch's --huawei-mode would do. One of the main problems of that built-in function is that you can't disable it, except by hacking the said file and recompiling the module. It would be impossible for you to check the content of the install storage. Plus, we will not know if your device is actually switching modes or just resetting once ... Anyway, I think the bug can be closed. Regards, Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634916: usb-modeswitch: seems to have no effect on Huawei E169
Am 09.08.2011 20:14, schrieb Didier Raboud: I'd be happy to close this bug, _but_ I don't want to lose information: in short, this is a kernel bug, right? Are you aware of an opened bug for the upstream Linux kernel ? If not, I propose to reassign this bug to the Debian kernel package and help its maintainers be aware of the issue. I'd say it's a question of philosophy if this can be considered to be a bug ... As far as I know, there is no current bug report regarding this issue. There was one coming quite close somewhat earlier: https://bugzilla.kernel.org/show_bug.cgi?id=12559 But it was tagged INVALID. To be frank, I don't know what to suggest. Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635464: usb-modeswitch: ZTE K3565-Z hang
Am 26.07.2011 03:08, schrieb Frederic MASSOT: I updated my EeePC 701 from Squeeze to Wheezy and my USB 3G stick is no longer recognized. I don't see any problem with mode switching here. Everything worked fine, the driver has bound. If other tools like UMTSmon or WVDial can work with the modem, then this would point to ModemManager as likely culprit. Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634916: usb-modeswitch: seems to have no effect on Huawei E169
Am 21.07.2011 21:40, schrieb Francesco Poli: In the two cases the outputs of the lsusb command are almost identical: the only difference is that the second time the device was identified as Bus 007 Device 005, instead of Bus 007 Device 003 I begin to suspect that you have a non-mode-switching device ... Usually, there is *no* serial interface initially, just an install partition containing the drivers. What happened on Windows when you plugged in for the first time? Have you been offered a driver installation immediately? Regards, Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634916: usb-modeswitch: seems to have no effect on Huawei E169
Am 20.07.2011 22:23, schrieb Francesco Poli (wintermute): I installed usb-modeswitch in order to prevent my USB HSDPA modem to be seen as a storage device. That may be a misunderstanding. After a mode switch, there may still be storage interfaces exposed in a modem device. The difference is that it's never the *first* interfaces as before switching. To see the difference between the modes, use lsusb -v -d 12d1:1001. Note that you may have to disable global switching in /etc/usb_modeswitch.conf to even see the initial (install) mode. crw-rw 1 root dialout 188, 1 Jul 20 22:44 /dev/ttyUSB1 crw-rw 1 root dialout 188, 2 Jul 20 22:44 /dev/ttyUSB2 crw-rw 1 root dialout 188, 0 Jul 20 22:44 /dev/ttyUSB0 ttyUSB0 should be your modem port. Do you have trouble using it? Regards, Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: usb-modeswitch: Devices no longer detected when plugged in at boot-time
Am 22.06.2011 09:56, schrieb Josua Dietze: If you want you can check for the other variables too; just before the case line, the values for v_id and p_id should be set. echo ums variables: v_id $v_id, p_id $p_id 2 I have to correct myself here; the variables mentioned are *not* relevant for the mode switching; they are used afterwards only, for the post-handling of the switched device. We need to look only at the bottom part of the script (upstream version): --x--x-- ( count=120 while [ $count != 0 ]; do if [ ! -e /usr/bin/tclsh ]; then sleep 1 count=$(($count - 1)) else exec /usr/bin/tclsh /usr/sbin/usb_modeswitch_dispatcher $@ 2/dev/null exit 0 fi done ) --x--x-- Here you could watch the value of $count, plus you could remove the error redirection of the dispatcher call to get a possible error report. Updated script: --x--x-- ( count=120 while [ $count != 0 ]; do echo ums: wait counter is $count 2 if [ ! -e /usr/bin/tclsh ]; then sleep 1 count=$(($count - 1)) else exec /usr/bin/tclsh /usr/sbin/usb_modeswitch_dispatcher $@ exit 0 fi done ) --x--x-- Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: usb-modeswitch: Devices no longer detected when plugged in at boot-time
Am 22.06.2011 10:24, schrieb Didier Raboud: FYI, the logs also contained the following linces (twice): '/lib/udev/usb_modeswitch' (stderr) '/lib/udev/usb_modeswitch: 33:' '/lib/udev/usb_modeswitch' (stderr) 'arithmetic expression: expecting EOF: 0x' '/lib/udev/usb_modeswitch' (stderr) '' This is very probably what we call a bashism. Debian's /bin/sh now points to /bin/dash. I have checked the script for bashisms. The problem may rather be a missing parameter from the script call. I recommend to add an echo line to put out the parameter list via error channel so that it may appear in the udev log. Right before the line p_id=$4: echo ums params: $@ 2 If you want you can check for the other variables too; just before the case line, the values for v_id and p_id should be set. echo ums variables: v_id $v_id, p_id $p_id 2 No way to check these commands right now, there may be errors. Regards, Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: usb-modeswitch: Devices no longer detected when plugged in at boot-time
Am 20.06.2011 15:03, schrieb Christian Kastner:
No luck, sorry...
O.K., time to remove the velvet gloves and get really nasty.
Two things to do (staying at version 1.1.8):
1. Edit /usr/sbin/usb_modeswitch_dispatcher,
insert these lines in the {Log} procedure before line 616:
--- snip ---
foreach line [split $msg \n] {
catch {exec /bin/logger -p syslog.warning ums: $line}
}
--- snip ---
2. Edit (create if not present) /etc/udev/udev.conf,
insert/change the following line:
udev_log=debug
Now activate usb_modeswitch logging in /etc/usb_modeswitch.conf and do the boot
test once more.
You should get a lot of udev: and ums: entries in /var/log/syslog.
Check the whole boot process and search for occurrences of usb_modeswitch and
ums. At least there should be indications that the little starter script
usb_modeswitch is actually started.
Examples:
udevd-work[548]: RUN 'usb_modeswitch '%b/%k'
udevd-work[548]: 'usb_modeswitch '/1-3:1.0'' started
Maybe you can spot a problem in the entries following that.
Josh
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: usb-modeswitch: Devices no longer detected when plugged in at boot-time
Am 18.06.2011 22:24, schrieb Josua Dietze: I'm just now working on the next version, 1.1.8, which tries to use a fallback in case of said quirks instead of bailing out. Now I have prepared a full test package of 1.1.8. I will release tonight if no quirks are reported. Get it here: http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-1.1.8-test.tar.bz2 http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-data-20110619-test.tar.bz2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630081: Overriding via /etc/usb-modeswitch.d doesn't work
I have prepared a full test package of 1.1.8, including the changes we were discussing. I will release tonight if no quirks are reported. Get it here: http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-1.1.8-test.tar.bz2 http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-data-20110619-test.tar.bz2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: usb-modeswitch: Devices no longer detected when plugged in at boot-time
Am 18.06.2011 16:11, schrieb Christian Kastner: I have attached a file with the following contents: 1. output of lsusb when plugged in at boot, then removed, then plugged back in, and `diff -U 0` a) from boot to removed That output is enough to confirm that there was no switching during bootup. To circle in further, can you install version 1.1.4 and just swap the little shell script usb_modeswitch in /lib/udev with the updated file from upstream 1.1.7 ? (Rename usb_modeswitch to usb_modeswitch.orig or whatever, then copy usb_modeswitch.sh from the source folder to /lib/udev/usb_modeswitch) To see if there was any switching, running lsusb is sufficient. If you see 12d1:1446 instead of 12d1:1001, switching did not happen. Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: usb-modeswitch: Devices no longer detected when plugged in at boot-time
Am 18.06.2011 19:09, schrieb Christian Kastner: On 06/18/2011 06:04 PM, Josua Dietze wrote: To circle in further, can you install version 1.1.4 and just swap the little shell script usb_modeswitch in /lib/udev with the updated file from upstream 1.1.7 ? With the above configuration, it's switched correctly: Interesting - now, can you do the same procedure with the file /usr/sbin/usb_modeswitch_dispatcher? The respective source file is usb_modeswitch.tcl which is renamed during a normal installation. Thanks for your precise reports, BTW! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: usb-modeswitch: Devices no longer detected when plugged in at boot-time
Am 18.06.2011 22:11, schrieb Christian Kastner: With 1.1.4 and udev, dispatcher from 1.1.7, it still appears to be switching properly at boot: So it's most likely a problem with the binary C program. There has been a change regarding determining the current device configuration since 1.1.6. We had few reports that some modems did not respond properly to the request about the configuration. Maybe that is a problem affecting your device during the boot process. I'm just now working on the next version, 1.1.8, which tries to use a fallback in case of said quirks instead of bailing out. Do you want to try it in the place of usb_modeswitch.c in the source folder? Just make and replace /usr/sbin/usb_modeswitch. Here's the link: http://www.draisberghof.de/usb_modeswitch/usb_modeswitch.c.gz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630081: Overriding via /etc/usb-modeswitch.d doesn't work
Am 16.06.2011 08:51, schrieb Didier Raboud: Le jeudi, 16 juin 2011 09.21:10, Alex Hermann a écrit : There are more software packages using this scheme (udev, mysql, pam) although most place all configs in /etc. I have no idea about the amount of support/bugreports this causes. IMHO, if a user changes/overrides the config he is responsible for tracking changes to the default config. Packaging scripts warning about them may help though. I agree with Alex here, although the warning bit is tricky to do correctly. That was my assumption too ... O.K., with your input I came to the conclusion that we will just accept a few cases of diminished consistency. And you are right, config files from version 1.0.3 should still work today and will continue to do so. IMHO the constant goal is to have zero overrides around: I mostly see the override mechanism as an easy way to work new config files out. Agreed. But in the case of these modem sticks this may be happening more often than for other types of hardware. They are distributed by telecom providers in big numbers and model variations are plentiful. BTW, I promise to release data package updates more often in the future ... To wrap it all up, the future priority logic would run like this: 1. Check out matching unpackaged files in /etc/usb_modeswitch.d. If there is a match, use it and issue a warning to syslog. (BTW, there may be left-over config files from earlier installations too; include this in the warning.) 2. If no match, check out matching unpackaged files in /usr/share/usb_modeswitch. No warning. 3. If still no match, check out matching packaged files in /usr/share/usb_modeswitch Note: (2.) is for the upstream installation and could be swapped with (3.). There should never be a mix of both types in /usr/share/usb_modeswitch. I think this would be consistent with your proposed patches, right? One more thing: should the empty folder /etc/usb_modeswitch.d be created initially? Probably including a short README? Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630081: Overriding via /etc/usb-modeswitch.d doesn't work
Am 16.06.2011 20:22, schrieb Didier Raboud: Le jeudi, 16 juin 2011 19.21:25, Josua Dietze a écrit : To wrap it all up, the future priority logic would run like this: As far as I can tell, this is mostly how the Debian-patched usb-modeswitch works. But it's better if it's upstream, sure. I have to refine the patches somewhat. For instance, the list order is essential when matching attributes. The Debian usb-modeswitch-data package already ships the empty /etc/usb_modeswitch.d folder, and its usage is documented in the /usr/share/doc/usb-modeswitch-data/README.Debian file. I see you're ahead of the game ... Thanks for the suggestions, everyone. While we're at it - what about a syslog warning like this (in GetConfig): usb_modeswitch: using overriding config file $config; make sure this is intended usb_modeswitch: please report any new or corrected settings; otherwise, check for outdated files Regards, Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: usb-modeswitch: Devices no longer detected when plugged in at boot-time
Am 07.06.2011 01:45, schrieb Christian Kastner: I rebuilt the package with (eventually) all patches dropped, unfortunately to no avail: /dev/ttyUSB[0-2] and /dev/gsmmodem are still not present at boot, and there is no log file in /var/log/ with EnableLogging=1. The main inconvenience is the problem that it's hard to get any log if you plug before booting. The file system is mounted read-only first, so switching may succeed but there is no logging at all. Are you sure the switching itself is not happening? Did you check the device ID after booting with the stick? Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630081: Overriding via /etc/usb-modeswitch.d doesn't work
Am 14.06.2011 12:06, schrieb Didier Raboud: Thanks for your time and skills ! Just want to let you know that I'm on the job now and following this exchange. Originally, the packed config file was not intended for default use on desktop systems. It kind of amazed me to see this happening on today's resource-loaded devices. Well, now we have it and it makes sense to consider a mix of packed and unpacked configurations, particularly when adding new device data or changing existing entries. I don't like the folder splitting though; the unpacked/edited files should be close to the other configurations. Why not use the /usr/share/usb_modeswitch folder, alongside the package? I propose to drop the check for the old config folder (/etc/usb_modeswitch.d) in the upcoming wrapper version altogether. Also, I think we can agree that in the now possible case of duplicate configurations (one unpacked, one packed) the unpacked file should have the higher priority. What do you think? Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630081: Overriding via /etc/usb-modeswitch.d doesn't work
Am 15.06.2011 21:56, schrieb Alex Hermann: On Wednesday 15 June 2011, Josua Dietze wrote: Why not use the /usr/share/usb_modeswitch folder, alongside the package? IMHO I think the folder change is not a good idea. The /usr/share folder is supposed to be under package manager control, not user control. I think overriding packaged configurations do belong in /etc. The current package (with this bug fixed) fits my use case perfectly and I think it also fits the Debian way of configuring software. You may have a point there; I'm not familiar enough with the package conventions. OdyX has just confirmed that fact :-) An override config file should have higher priority than shipped config of course. O.K., so let's assume a user puts a changed/added config file into /etc/usb_modeswitch.d. It is preferred over the files in the package. One day there is a package update, and the new/changed configuration now comes included with the new package, probably improved over the manual file or with new parameters. What should happen then? The priority would have to be reversed ... Or the package install routine should notice the conflict and ask about a user decision. For a moment I thought about checking file mod time. But it's very error-prone too. It's getting a wee bit messy, I'm afraid. Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: usb-modeswitch: Devices no longer detected when plugged in at boot-time
Am 06.06.2011 00:59, schrieb Christian Kastner: usb-modeswitch no longer detects devices when the device is already plugged in at boot time. When the device is plugged later, into an already running system, everything works as expected. With version 1.1.4 from Squeeze, everything works fine in both cases. Can you test with the upstream source package of 1.1.7? There was a similar report before where we circled in on the Debian patches, but the reporter was not able to follow through. The device in question is a Huawei E1750. It is quasi-permanently plugged into my gateway router as a fallback in case my main ISP connection goes down, but I can reproduce this issue with my desktop machine too. There might be an additional quirk. The latest data packages are using a different switching command for Huawei devices, by request from Huawei engineers. It turned out that some modems are getting a different target ID with that command which may not be included with the respective config file. I suspect that may be the reason why you don't get the gsmmodem link. Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588867:
Am 16.05.2011 16:23, schrieb Carlo Marchiori: No I didn't check, I wouldn't know what to check actually, I'm IT literate but just a Debian user. With checking, I just meant to have a look if it's there at all ... /lib/udev/hotplug.functions This is the Debian patch for the little shell wrapper: http://patch-tracker.debian.org/patch/series/view/usb-modeswitch/1.1.7-1/03_use_udev_specifics.patch Maybe you can re-install the Debian packages and play around with the shell wrapper, like replacing the patched code with the upstream version (marked red in the display linked above) ... Regards, Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612690: Please move data files to /lib/ or /usr/share
The check (and wait) for /usr availability is provided by the starter script in /lib/udev. It will run in background and not holding up the udev process. Since the shell for the wrapper script sits in /usr/bin, this tree is needed anyway. I thoroughly tested on seven different distros. The cold boot processing worked reliably. Concerning the timing, it makes sense to run the whole switching procedure detached from the boot process because the devices concerned do need from 2 to 20 seconds to return in their new mode. Josua Dietze Michael Biebl bi...@debian.org schrieb: Hi Didier Am 10.02.2011 00:31, schrieb Josua Dietze: Am 10.02.2011 00:11, schrieb Michael Biebl: Please consider moving those files to /usr/share, or if they are needed during boot to /lib/usb-modeswitch. The files might in fact be needed during boot. With today's upload the files were moved out of /etc/ into /usr/share. Have you read Josua's comment, that those files are needed during boot? With the files in /usr/share, you will run into problems if /usr is on a separate partition because udev is run rather early before boot (before other partitions are mounted). In case your modem is already attached during boot, it won't be switched, unless you plug it out and in again. Have you considered that? Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#612690: Please move data files to /lib/ or /usr/share
I have changed this upstream in version 1.1.7 which was just released. No more /etc/usb_modeswitch.d ... Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612690: Please move data files to /lib/ or /usr/share
Am 10.02.2011 00:11, schrieb Michael Biebl: usb-modeswitch-data ships around 150 small files in /etc/usb_modeswitch.d/ which don't look like configuration files at all, but more like a hardware database. ... Please consider moving those files to /usr/share, or if they are needed during boot to /lib/usb-modeswitch. This is already on the ToDo list for the next version of usb-modeswitch as it was discussed with the Debian package maintainer. I'm planning the release to be out in two weeks or so. The location of the data files has to be reflected in the program obviously. The files might in fact be needed during boot. Josua Dietze (upstream) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587776: gsmmodem symlink missing
I believe we will not get any further regarding this error report. I was not able to provoke a sitution where the symlink was *not* generated on my various systems - except if the data package was an older release. The command line parameter for the symlink function has changed slightly in wrapper version 1.1.4 which has to be reflected in the udev rule. Since we obviously cannot expect any more help from the reporter, I'm pleading for rejecting the error report after the version update. Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587776: symlink still missing
Of course there is an implementation for the multi-interrupt workaround in version 1.1.4. But if you get NO symlink at all, there might be annother problem which is unrelated. Are you saying that you don't get any per-interface logs with the test script? And if you are not willing to help finding the problem, can we agree to close this bug? Josua Dietze Nils Radtke nils.rad...@think-future.de schrieb: Hi, There is specific information and even a patch showing how it should work. Not working is precise enough, as it is: Not Working. Also, there's the indication that there's no symlink. What else do you need? Yeah, except for the log, there's nothing new to see. It was tested using latest packages. I'm tired of trying stuff that's bound to fail because the real issue never got investigated nor implemented. We finally stick to the patched versions. Cheers On Tue 2010-09-14 @ 09-28-16AM -0400, Josua Dietze wrote: # Not working is a bit unspecific. Please post the per-interface logs that the custom dispatcher script puts out. And check if you are using the latest data package. # # Josua Dietze # # # # Nils Radtke l...@think-future.de schrieb: # # Using 1.1.4-1 w/ the dispatcher packaged and the one w/ md5sum # # 4dbee5f67f0fc15c8a949cabd8df4bfe usb_modeswitch_dispatcher # # does NOT work. # # Reliably working: 1.1.2-3 + patch above. # Working 1.1.3-1, w/ symlink but errors in log, occasionally missing link, time to appearance of symlink is very long. # # # # # # =-- # Gesendet von meinem Dell Streak. -- =-- Gesendet von meinem Dell Streak.
Bug#587776: symlink still missing
Not working is a bit unspecific. Please post the per-interface logs that the custom dispatcher script puts out. And check if you are using the latest data package. Josua Dietze Nils Radtke l...@think-future.de schrieb: Using 1.1.4-1 w/ the dispatcher packaged and the one w/ md5sum 4dbee5f67f0fc15c8a949cabd8df4bfe usb_modeswitch_dispatcher does NOT work. Reliably working: 1.1.2-3 + patch above. Working 1.1.3-1, w/ symlink but errors in log, occasionally missing link, time to appearance of symlink is very long. =-- Gesendet von meinem Dell Streak.
Bug#587776: gsmmodem symlink missing
Am 20:59, schrieb Nils Radtke: There's no gsmmodem link created on plugging in. Log below. Switching seems to have worked O.K., so the log does not help much with the symbolic link feature. I reapplied the verbose version of the symlink procedure that I had posted for testing to the current wrapper script. Please run it in the place of /usr/sbin/usb_modeswitch_dispatcher. If the symlink rule in the rules file is working, you get a log for every interface in /var/log which should look like these examples: USB_ModeSwitch log from Mon Sep 06 21:00:13 CEST 2010 My port is ttyUSB0, my interface is 0 Checking my endpoints in /sys/devices/pci:00/:00:12.2/usb6/6-6/6-6:1.0 in epDir /sys/devices/pci:00/:00:12.2/usb6/6-6/6-6:1.0/ep_81 in epDir /sys/devices/pci:00/:00:12.2/usb6/6-6/6-6:1.0/ep_01 -- I am not an interrupt port Return empty name and exit USB_ModeSwitch log from Mon Sep 06 21:00:13 CEST 2010 My port is ttyUSB2, my interface is 3 Checking my endpoints in /sys/devices/pci:00/:00:12.2/usb6/6-6/6-6:1.3 in epDir /sys/devices/pci:00/:00:12.2/usb6/6-6/6-6:1.3/ep_84 found interrupt endpoint /sys/devices/pci:00/:00:12.2/usb6/6-6/6-6:1.3/ep_84 -- I am an interrupt port Looking for lower interrupt endpoints in ifDir /sys/devices/pci:00/:00:12.2/usb6/6-6/6-6:1.0 in epDir /sys/devices/pci:00/:00:12.2/usb6/6-6/6-6:1.0/ep_81 in epDir /sys/devices/pci:00/:00:12.2/usb6/6-6/6-6:1.0/ep_01 in ifDir /sys/devices/pci:00/:00:12.2/usb6/6-6/6-6:1.1 in epDir /sys/devices/pci:00/:00:12.2/usb6/6-6/6-6:1.1/ep_82 in epDir /sys/devices/pci:00/:00:12.2/usb6/6-6/6-6:1.1/ep_02 in ifDir /sys/devices/pci:00/:00:12.2/usb6/6-6/6-6:1.2 in epDir /sys/devices/pci:00/:00:12.2/usb6/6-6/6-6:1.2/ep_03 in epDir /sys/devices/pci:00/:00:12.2/usb6/6-6/6-6:1.2/ep_83 -- No interrupt interface below me Return symlink name gsmmodem and exit - Here is the test version: http://www.draisberghof.de/usb_modeswitch/usb_modeswitch_dispatcher.gz Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590902: usb-modeswitch-data: 19d2:2000 conflicts with 61-mobile-action.rules from udev
Am 22.08.2010 18:43, schrieb er...@ikki.ws: The 19d2:2000 entries are only in 40-usb_modeswitch.rules and etc/usb_modeswitch.d/19d2:2000. Thanks for confirming. From my point of view I think we could as well close this bug. Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590902: usb-modeswitch-data: 19d2:2000 conflicts with 61-mobile-action.rules from udev
Am 21.08.2010 01:27, schrieb er...@ikki.ws:
Some questions:
What happens if you leave the usb_modeswitch config file intact but
disable the rule in 61-mobile-action.rules (out-comment, reload rules) ?
Ok, usb_modeswitch config file intact (19d2:2000)
1) 61-mobile-action.rules, it has the following warning:
# ATTENTION: DO NOT USE THIS FILE FOR ANYTHING EXCEPT
# MOBILE ACTION CABLES. DO NOT USE IT FOR 3G DEVICES!
So I guess this is not the file to modify, but anyway I comment out the
following rule:
#ATTRS{idVendor}==0df7, ATTRS{idProduct}==0800,
RUN+=mobile-action-modeswitch -v 0x%s{idVendor} -p 0x%s{idProduct} -t
mobile-action-8280p
If I get it right, you posted the error when you ran an earlier
version of udev (or udev-extras). For a certain time it came with an
entry for 19d2:2000 in that same file which conflicted with
usb_modeswitch. (Otherwise your bug title wouldn't have made much
sense, right?)
But Dan Williams of Redhat who oversights that package has stated that
he would reduce his switching attempts to exactly one device, an
active USB cable named Mobile Action. All others should be taken
care of by usb_modeswitch.
So I suppose this is what we are seeing now. Can you confirm that the
conflict no longer exists? If there is no entry for 19d2:2000 in any
rules file except in 40-usb_modeswitch.rules, then there is no way to
have a conflict.
To be on the safe side, check also the rule files in
/etc/udev/rules.d. With a simple grep 19d2.*2000 * you should be
able to catch any conflicting entry.
What happens if both ways are intact and you change the config file
/etc/usb_modeswitch.d/19d2:2000 and add the following line ?
MessageContent3=555342431234567820008c85010101180101010101
The result:
- Modem works like a charm :)
I think this is the solution.
This command is added to the latest usb-modeswitch-data package
(version 20100817). So your modem should work with this release
out-of-the-box.
Cheers,
Josh
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591761: Bug#591722 Grave Error
I released a new version which does not use the temp file mechanism anymore. And it's fit for boot time usage now (tested on Debian 5 and many other systems). This should fix this error. Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587776: usb-modeswitch: multi-interrupt umts devices patch against 1.1.2-3
I released a new version (1.1.4) which incorporates the changes mentioned earlier. I could test it myself with single-interrupt devices only but I'm very confident that it will fix the problem. Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591760: Bug #591765: usb-modeswitch: Needs to sleep multiple times before forking.
I released a new version (1.1.4) where the changes of Didier's fix were incorporated. I use the wait_for_file function inline because no other distribution I tested on provides hotplug.functions. The call of the dispatching sh script returns immediately (as did the double call of the tcl script in earlier versions), but in addition the whole package is now boot-proof. This was tested on Debian 5 and many other systems. The sleep periods are still part of the process but they are not blocking anything except the script (well, they are supposed to). Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591765: Bug #591765: usb-modeswitch: Needs to sleep multiple times before forking.
I released a new version (1.1.4) where the changes of Didier's fix were incorporated. I use the wait_for_file function inline because no other distribution I tested on provides hotplug.functions. The call of the dispatching sh script returns immediately (as did the double call of the tcl script in earlier versions), but in addition the whole package is now boot-proof. This was tested on Debian 5 and many other systems. The sleep periods are still part of the process but they are not blocking anything except the script (well, they are supposed to). Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591722: #591722 usb-modeswitch: Broken assumption on availability of /usr/bin/ and /var/log/ at boot time
I released a new version (1.1.4) where the changes of Didier's fix were incorporated. I use the wait_for_file function inline because no other distribution I tested on provides hotplug.functions. The whole package is now boot-proof. This was tested on Debian 5 and many other systems. Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591760: usb-modeswitch: Recursive greps over udev rules slows down the boot
I released a new version (1.1.4) from which the grep lines are removed. Oh, and it has never been called recursively ... Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587776: usb-modeswitch: multi-interrupt umts devices patch against 1.1.2-3
Am 18.08.2010 15:58, schrieb Didier Raboud: On Wed, 18 Aug 2010 15:48:26 +0200, Nils Radtkel...@think-future.de wrote: Trying usb-modeswitch 1.1.3-1 Huh !? 1.1.3-* doesn't include your patch, nor upstream's. It will come in 1.1.4-1, which is expected in some days. I released it last night. I have CC'd Nils Radtke among others. Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587776: usb-modeswitch: multi-interrupt umts devices patch against 1.1.2-3
Am 18.08.2010 15:48, schrieb Nils Radtke: log msgs of this kind appear in dozens lately: If you intend to blame me for all kinds of system problems, go ahead and do it, I can live well with it. But I suggest you do it via private e-mail, because the exchange may not be overly interesting for the rest of the community. But, wait - here you are complaining about an untested release where the test version was available and made known to you a month ago ? And then you state you were busy ? Are you aware of a certain level of contradiction here ? Oh, and I pledge that I will not ask about your definition of going berserk :-) Josua Dietze - Berserk Upstream -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578024: usb-modeswitch-data: Avoid splitting /etc/usb_modeswitch.d/
Release 1.1.4 of the usb-modeswitch package introduces the possibility to work with a tarball of the config files. From usb-modeswitch-data package version 20100817, there is a new make target install-packed which creates a single file configPack.tar.gz in /etc/usb_modeswitch.d. On my system its size is 6688 Bytes. This may be useful on systems with constrained resources. Regards, Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591722: Undo posting #62
Please ignore message #62. It was intended for bug #591761. Sorry, temporary loss of track. Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591761: usb-modeswitch: Insecure usage of /tmp/gsmmodem_*
Am 05.08.2010 19:50, schrieb Marco d'Itri: You are trying to solve this at the wrong level. You should use an IMPORT rule triggered by KERNEL=ttyS* (or something like this) and then a SYMLINK rule triggered by an exported variable. Anyway, you should not manually create symlinks in /dev. If you need help, ask on the linux-hotp...@vger mailing list. The IMPORT feature might be what was missing in my tool box. Turns out the How-To I trusted did not mention it at all ... I think I can get rid of the temp file alltogether. Working on it. Anyway, you should not manually create symlinks in /dev. I don't think I do. I'm using the PROGRAM and SYMLINK features of udev in a rule looking for new ttyUSBs and just return an empty name if the port doesn't have an interrupt interface. Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591722: #591722 usb-modeswitch: Broken assumption on availability of /usr/bin/ and /var/log/ at boot time
Am 07.08.2010 18:12, schrieb Didier 'OdyX' Raboud: Hi Marco and Josh, So here's a first patch for this bug. Marco: would that sound okay for you ? http://git.debian.org/?p=collab-maint/usb-modeswitch.git;a=commitdiff;h=a41dcc4 That's absolutely fine with me, taking the alsa way. For the next release I just have to check the availability of the hotplug functions on the other distros. Thanks, OdyX! Josh -- Man is the only creature on earth enabled to take a warm meal while flying. Loriot -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
