You don't need to uninstall usb_modeswitch to disable it. There is an
option in /etc/usb_modeswitch.conf to do that.
To actually identify the problem, you would have to reinstall it and
generate a log. This is also enabled by an option in
/etc/usb_modeswitch.conf.
--
You received this bug notifi
You are not clearly saying what the actual issue is.
Is the modem resetting on its own?
If so, what happens when you disable usb_modeswitch globally? Does the
behaviour change in any way?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
Josue, the first step would be to fix your usb_modeswitch package
installation, maybe by re-installing it. Once you see in your logs that
it runs normally when the stick is inserted, check if your problem
persists.
--
You received this bug notification because you are a member of Desktop
Packages
To elaborate, the error means that usb_modeswitch was not run at all, so
anything that happens afterwards is unrelated to the package.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-modeswitch in Ubuntu.
https://bugs.launchpad.net/bu
In both the "good" and the "bad" syslog, this error sticks out:
Jan 19 18:24:06 ubuntu systemd[6325]: usb_modeswitch@1-3.service: Failed
at step EXEC spawning /usr/sbin/usb_modeswitch_dispatcher: No such file
or directory
--
You received this bug notification because you are a member of Desktop
I don't doubt that it was working in earlier versions.
The point is that the cause of the problem is somewhere else, probably in the
USB driver.
It's not a usb_modeswitch problem.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-mode
Your log shows many disconnects and reconnects, as Lars has noticed.
If you have not unplugged your modem manually, then there is a problem
with the USB connection. Note that it may also be driver-related, so
does not happen on Windows.
In any case, usb_modeswitch is not the problem. The mode swi
Ah, that makes sense. So these are not manual disconnects then.
Why would the first run of usb_modeswitch (during boot) take so long?
Just system load perhaps?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-modeswitch in Ubuntu.
htt
I have trouble pinpointing the actual problem. Did you want to say
"15-25 seconds" instead of "minutes"?
The only unusual behaviour I see in your log is that the very first run
of usb_modeswitch takes roughly 40 seconds. Afterwards, everything seems
to be fine, modem and storage.
I suppose the la
ALL distributions that I'm familiar with are adding a symlink
"/usr/bin/tclsh" to whatever specific version of the shell is included
when tcl is installed.
Update: just checked, and the symlink "tclsh" is included with the
current tcl package of Debian Sid as well as with the package of Debian
Str
As a reminder, the file
http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-versions.xml
can be monitored for updates; it has download link and md5 value.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-modeswitch in Ubuntu.
ht
I have released upstream version 2.6.1 which includes the fixes for
recently reported problems.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-modeswitch in Ubuntu.
https://bugs.launchpad.net/bugs/1676763
Title:
usb_modeswitch_dis
Sebastien, I understand your concerns with regard to jimtcl. However,
the tcl package seems to be well maintained, with very few bugs (2) in
the current version, one of low urgency and one undecided.
Anyway, it's not my decision to make obviously. I trust that you know
what's best for Ubuntu.
--
dle USB devices with multiple modes
* Version 2.5.2 (C) Josua Dietze 2017
* Based on libusb1/libusbx
! PLEASE REPORT NEW CONFIGURATIONS !
DefaultVendor= 0x05c6
DefaultProduct= 0x1000
StandardEject=1
[New Thread 0x77d58700 (LWP 16370)]
Look for default devices ...
fo
I've made an attempt to fix the problem of interfaces missing in the
original Tcl wrapper. I intend to release 2.6.1 soon.
If anybody wants to test, the files are here:
https://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?p=19605#p19605
--
You received this bug notification because you a
Let me just explain shortly why I'm sticking with Tcl for the
dispatcher.
That script language is perfectly fitted for string and file parsing. At
the same time, it's much better human-readable than a Bash or Perl
script. I had people adding fixes to the wrapper script who weren't even
familiar wi
h -W -v 05c6 -p 1000 -K
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Take all parameters from the command line
* usb_modeswitch: handle USB devices with multiple modes
* Version 2.5.2 (C) Josua
;/lib/x86_64-linux-gnu/libthread_db.so.1".
Take all parameters from the command line
* usb_modeswitch: handle USB devices with multiple modes
* Version 2.5.2 (C) Josua Dietze 2017
* Based on libusb1/libusbx
! PLEASE REPORT NEW CONFIGURATIONS !
DefaultVendor= 0x05c6
Default
@Sebastien, I just checked and the entry "05c6:1000:uMa=Qualcomm"
suggested in bug #1823540 was indeed added to the last (current) data
package release.
So it was checked alright. The bug can probably be closed as fixed.
--
You received this bug notification because you are a member of Desktop
P
Unfortunately, no VCS. However, there is a little helper link that can
be monitored and which is up to date, including download link and MD5:
https://draisberghof.de/usb_modeswitch/usb-modeswitch-versions.xml
Regarding bug #1823540, that's a case with an issue similar to this one.
05c6:1000 is a
@Sebastian, I am happy to correct myself in that Ubuntu is obviously NOT
generally slow in picking up the latest update of the data package. You
do have the current version now.
I was rather referring to earlier LTS releases. I'm not even sure if
that's still the case with recent LTS versions.
Fa
I was unclear, sorry.
I'm referring to this very bug report. Upstream is me :-)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-modeswitch in Ubuntu.
https://bugs.launchpad.net/bugs/1878921
Title:
USB 3 NVMe SSD dongle doesn't fli
Well, I suppose the maintainers are following this bug report, or at
least they should.
Upstream has confirmed the bug and provided a solution.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-modeswitch in Ubuntu.
https://bugs.launch
Thanks for the lsusb output!
It enabled me to provide a solution.
usb_modeswitch can check for additional attributes beside the USB ID,
precisely *because* of those IDs being re-used for different devices.
The original idea was to have one ID for each device model or at least
for one series of dev
I have found a detailed lsusb listing for the Pico Pix 1120. Now we need
to compare it to the listing of your device *before* the mode switch.
Cedric, could you post such a listing svp?
You can disable usb_modeswitch the hard way by renaming
usb_modeswitch_dispatcher. It usually sits in /usr/sbin
That USB ID is in fact in the 'data base' of usb_modeswitch. It was
originally used for the Philips PicoPix 1020 Projector.
That's what you get when the same USB ID is used for multiple unrelated
devices ...
The clean solution would be to use additional USB attributes to try and
tell the projecto
The dot in the kernel name of a USB device indicates that a device is connected
via a hub.
In theory, this can even be cascaded, leading to names like "2-1.2.1.3.4"
So the hardware difference is that the ports in the Toshiba are not
'primary' but exposed through an internal hub as opposed to the
Without being familiar with the Ubuntu flavour of usb_modeswitch - can
this be a permission issue?
Does the usb_modeswitch wrapper and program run in the proper user /
group context? It needs to be able to read attributes in the "sys" tree.
If the permissions are not correct, that would explain w
Thanks for the thorough analysis!
I will check your patches and apply them upstream accordingly. It's
amazing what device engineers come up with to make life more
"interesting" ...
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-mode
Am 27. August 2019 19:17:09 GMT+02:00 schrieb Gunnar Hjalmarsson
<1800...@bugs.launchpad.net>:
>@Josua: Thanks for that explanation.
>
>Since you are here, may I take the opportunity to ask a question. I
>think that Mathieu would prefer that TCL somehow is compiled into a
>binary, and that's what
Am 27. August 2019 04:04:34 GMT+02:00 schrieb Gunnar Hjalmarsson
<1800...@bugs.launchpad.net>:
>
> The upstream source has a jim/ folder with a lot of stuff, but that
> folder is excluded in the Debian/Ubuntu source.
The inclusion of the jim shell code is just meant to be a suggestion for
users w
Syncing Ubuntu usb_modeswitch is hardly possible because it's a fork of
the original, using a C implementation of the wrapper script.
I'd just throw out anything that's related to module loading and driver
binding.
--
You received this bug notification because you are a member of Desktop
Package
Correction:
The mode that Huawei calls "HiLink" is No.1, not No.2.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-modeswitch in Ubuntu.
https://bugs.launchpad.net/bugs/1819362
Title:
HUAWEI E3531 HSPA+ USB Stick "please report th
Addendum:
The "official" switching message suggested by Huawei may bring up either
mode No.1 or mode No.2 in recent models. If No.1 shows up, there is a
possibility that the "HuaweiAltMode" message may bring up No.2 instead.
This is up to the user though, there is no comprehensive information
ava
Not sure if and how SMS features are included there - that's not my field of
expertise.
Josua Dietze (usb_modeswitch upstream)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-modeswitch in Ubuntu.
https://bugs.launchpad.net/bugs/1819362
As you noticed, there is already a usb_modeswitch configuration for the USB ID
19d2:0083.
However, the scope of its application is narrowed to devices which have the
string "WCDMA" in their product description. This applies to ZTE modem sticks.
Now, your phone's product description is "ZTE HSUSB
udippel, instead of ranting generally you could just use Debian instead
of Ubuntu. It's likely that you would not run into this bug.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-modeswitch in Ubuntu.
https://bugs.launchpad.net/bugs
Thanks - will be fixed upstream soon(ish).
In the definition of "long_options" there is one line missing:
...
{"huawei-new-mode", no_argument, 0, 'J'},
...
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-
Hint:
It may well be that there is a timing problem if the dispatcher tries to
read the values when the storage driver has not completed the
initialization of the storage interface.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-mod
Yes, it's correct to disable mode-switching when checking out the SCSI
attributes. This is what usb_modeswitch sees when a phone/modem is
plugged in. Then it has to determine if any action is required.
Bottom line:
The dispatcher part of the usb_modeswitch Ubuntu fork has trouble
reading the SCSI
The problem is obvious in the log from #14:
Warning: SCSI attribute "vendor" not readable.
Warning: SCSI attribute "model" not readable.
Warning: SCSI attribute "rev" not readable.
The filter "sMo=U209" which should prevent usb_modeswitch from doing
anything in this case does not work - because t
The problem is obvious in the log from #14:
Warning: SCSI attribute "vendor" not readable.
Warning: SCSI attribute "model" not readable.
Warning: SCSI attribute "rev" not readable.
The filter "sMo=U209" which should prevent usb_modeswitch from doing
anything in this case does not work - because t
I have released an updated version of usb_modeswitch (upstream). This
version works very reliably with the Cisco AM10, as tested with my own
device.
See
http://www.draisberghof.de/usb_modeswitch
--
You received this bug notification because you are a member of Desktop
Packages, which is subscrib
nt =0x89
MessageContent
="55534243785634120100860100"
CheckSuccess =4
Ubuntu 13.10 (usb_modeswitch Version 1.2.3 (C) Josua Dietze 2012) still uses
BAD configPack.tar.gz/0af0:d001 config:
# Option GlobeTrotter GI1515
TargetVendor= 0x0a
01
MessageEndpoint =0x02
ResponseEndpoint =0x89
MessageContent
="55534243785634120100860100"
CheckSuccess =4
Ubuntu 13.10 (usb_modeswitch Version 1.2.3 (C) Josua Dietze 2012) still uses
BAD configPack.tar.gz/0af0:d001 config:
# Option GlobeTrot
*** This bug is a duplicate of bug 992639 ***
https://bugs.launchpad.net/bugs/992639
LJ, you can just create a new file and add the option line.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-modeswitch in Ubuntu.
https://bugs.l
BTW, the use of "usbserial" is not recommended for 3G modems.
To bind a driver to the modem, do this:
# modprobe option
# echo "12d1 14a8 ff" > /sys/bus/usb-serial/drivers/option1/new_id
Ubuntu Precise is still using data package release "20120120"; the modem ID was
first reported in April.
-
It has been added to "usb-modeswitch-data-20120531", released on May 31st.
This version is in Debian "wheezy (testing)".
The current version is 20120815, which is in Debian "sid (unstable)".
This is the content of the respective config file ("12d1:14b5"):
--
# Hua
ked config collection /usr/share/usb_modeswitch/configPack.tar.gz
Searching entries named: /usr/share/usb_modeswitch/1c9e:9e00*
Searching overriding entries named: /etc/usb_modeswitch.d/1c9e:9e00*
SCSI attributes not needed, moving on.
Reading config file: /run/usb_modeswitch/current_cfg
GreDi,
your log shows that this problem is indeed the same as in bug #990337.
A fix is on the way.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-modeswitch in Ubuntu.
https://bugs.launchpad.net/bugs/996664
Title:
Huawei E173 do
Since this is evidently hardware-dependent, the minimum value should
better be confirmed by all reporters.
In any case, 2 or 3 seconds is still an improvement against the earlier
kernel default which was 5 seconds, IIRC.
--
You received this bug notification because you are a member of Desktop
P
O.K., so the usb_modeswitch package should install a file in
"/etc/modprobe.d" named "usb-storage.conf" with this content (or so):
--x--
# Increase the default delay to avoid conflict with usb_modeswitch
options usb-storage delay_use=3
--x--
Is there a way to check if there are other packages wh
Here is a little HowTo for conducting the test I requested:
There is a list (OR a package) of small config files in
/usb/share/usb_modeswitch.
Pick the one that matches your stick's ID in *install mode* (e.g. if the mode
switch fails or if switching is disabled globally in
/etc/usb_modeswitch.co
People,
I need *anybody* with the USB 3.0 problem test the "ReleaseDelay"
parameter.
If that does not work, there is still plan B which is to alter the
default "delay_use" option with the installation of usb_modeswitch. I
can also let it check the setting with every run.
This would of course af
Again:
Please post a log of the mode-switching process. See post #4.
** Changed in: usb-modeswitch (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-modeswitch in Ubuntu.
https://bugs.l
Please create a usb_modeswitch log file by editing
/etc/usb_modeswitch.conf and set EnableLogging to 1.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-modeswitch in Ubuntu.
https://bugs.launchpad.net/bugs/755342
Title:
Samsung Xco
Has anybody been able to test the "ReleaseDelay" parameter ?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-modeswitch in Ubuntu.
https://bugs.launchpad.net/bugs/979697
Title:
Modeswitching modem not working with some USB 3.0 host
There is nothing orderly about the whole mode-switching business. From
the system's view it's no different than a physical unplug and reinsert
of a device. The word "API" does not come to my mind at all.
For usb_modeswitch as such, timing is not important - in theory. The
tipping point *should* be
There might be a loose relation to bug #992639, where the storage driver
attribute "delay_use" has some relevance:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/992639
Anyway, all these timing problems seem to be rather system-specific.
Apart from pointing to the tweakable parame
I was not able to reproduce this on my machine, which has a Renesas chip
for the USB 3.0 ports. Kernel is "3.2.0-27-generic".
No xHCI error, no problems with mode switching ...
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to usb-modeswit
In reply to #60, Thomas Hood:
The first report contains "CurrentDmesg.txt". According to this, the
option driver has bound and serial ports are available. So
usb_modeswitch has fulfilled its task.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscr
It would be good to know what the default 'delay_use' is on 12.04 and
what it was on *previous* Ubuntu versions.
Originally, this was set to 5 seconds in the storage driver, with SCSI hard
disks in mind. This may have been changed in the kernel as the main users of
the driver nowadays are flash
As far as I can see, these problems are related to modem-manager, not
usb_modeswitch.
** Package changed: usb-modeswitch-data (Ubuntu) => network-manager
(Ubuntu)
** Changed in: network-manager (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a mem
If I may refer to my comment #85 - I had a look at the "working" and
"nonworking" log of modem-manager and pointed out the obvious
differences.
I strongly suspect that the newer version of MM is attempting to make use of
the diagnostic port, which can give status information (like signal strength
One striking difference between the two modem-manager.logs is that in
11.10 there is communication with ttyUSB1 in parallel, whereas in 11.04
it is "type ignored" after the probing.
The commands that are going to ttyUSB0 seem not to be different in both
logs, but the response from there stops at t
Can you extract the modem-manager.log from 11.04?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/868034
Title:
Huawei E220 can't connect on Ubuntu 11.10
Status in “linux” pac
> Is it possible for an E220 to be left in the "wrong"
> state when it's switched off?
Not that I know of. Power gone = back to install mode. Always. No known
exceptions.
This would not make sense anyway: the point of the whole process is to
have the (Windows) drivers available at *every* plugin
The dmesg output from comment #73 does not indicate a problem. This is
exactly what will happen every time during the device mode switch. The
first device will 'vanish' and then return as a second one with a very
different setup.
--
You received this bug notification because you are a member of D
The command from comment #13 will do nothing but send a standard device
reset control message to the modem. Any tool using libusb could do that,
so it's not a genuine property of usb_modeswitch. It was added just for
convenience.
And the workaround is quite logical: if something is screwing up the
I think I have not been clear enough; the built-in switching function in the
kernel is not related to the bug reported here. It has not changed since the
2.6.2x versions, AFAIK.
It just confirmed the fact that usb_modeswitch could not be involved with this
bug in any way.
My assumption (rather
It's the kernel.
I have forgotten about it - there is a switching function in usb-storage
from the time when usb_modeswitch wasn't wide-spread. The affected
devices are listed in "unusual_devs.h".
The bottom line is that usb_modeswitch can't be responsible for the
reported bug. It is not needed f
If udev starts usb_modeswitch, but usb_modeswitch can't find the device
when searching the busses, it means that something else is affecting the
device in the meantime. This should be visible when calling "dmesg"
after plugging in.
Either it's a driver thing (I'll check the source code of usb-stor
Furthermore I don't recommend to blacklist the "usb-storage" module.
Several modems want to be initialized before the mode switch can
successfully happen. The storage driver should not be able to keep any
device from switching.
Again, please enable usb_modeswitch's logging.
--
You received this
This is not a usb_modeswitch problem, as mode switching and serial port
creation have completed fine.
Re-assigning to "network-manager".
** Package changed: usb-modeswitch (Ubuntu) => network-manager (Ubuntu)
--
You received this bug notification because you are a member of Desktop
Packages, w
** Package changed: usb-modeswitch-data (Ubuntu) => network-manager
(Ubuntu)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/630416
Title:
usb device is recognized as "USBModem
** Changed in: usb-modeswitch-data (Ubuntu)
Status: New => Invalid
** Package changed: usb-modeswitch-data (Ubuntu) => network-manager
(Ubuntu)
** Changed in: network-manager (Ubuntu)
Status: Invalid => New
--
You received this bug notification because you are a member of Desktop
** Changed in: usb-modeswitch-data (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/868034
Title:
Huawei E220 can't connect on Ub
To determine if the problem is caused by usb_modeswitch, please enable logging
in
/etc/usb_modeswitch.conf.
Post the largest file (name starting with "usb_modeswitch") that is
created in /var/log after you plugged the device.
DON'T comment out any entry in the "rules"file !!
--
You received th
78 matches
Mail list logo
