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 Ubuntu
Bugs, which is subscribed to Ubunt
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 Ubuntu
Bugs, whi
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1910982
Title:
ZT
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 Ubuntu
B
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.ne
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1676763
Title:
usb_modeswitch_dispatcher crashed with SI
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.
--
I've made an attempt to fix the problem upstream, largely along the
lines of Sebastien's patch. 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 y
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
Addendum:
Of course the actual crash is caused by accessing the "config" structure
that's likely empty after the failed function.
-x-x-x-
for (i=0; ibNumInterfaces; i++) {...}
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://
Hmm, simone-c wrote:
"I tried to compile latest available version: usb-
modeswitch-2.6.0.tar.bz2 (md5: be73dcc84025794081a1d4d4e5a75e4c) and it
does not crash."
Generally, not many changes are made anymore regarding the core program.
Strangely enough, there wasn't the slightest change in the
deta
@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 Ubuntu
Bu
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1878921
Title:
USB 3 NVMe SSD dongle doesn't flip
To manage notificati
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1878921
T
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https
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 Ubuntu
Bugs, wh
Correction:
The mode that Huawei calls "HiLink" is No.1, not No.2.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1819362
Title:
HUAWEI E3531 HSPA+ USB Stick "please report the device ID to the Linu
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1819362
Title:
HUAWEI E
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/755342
Title:
Samsu
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
h
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
http
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 Ubuntu
Bugs, which is subscribed to
Correction for post #4:
When you edit the config file, also add the following lines:
MessageEndpoint =0x02
ResponseEndpoint =0x89
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1261923
Title:
wrong
Somehow the "Interface" paramater has never made it into the data
package ...
I'll include it with the next release; however, a small change in the
program package is required as well. This applies to the upstream
wrapper code which filters out all devices with interface 0 class
anything other tha
*** 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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/97969
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
Bug #996664 is a duplicate of this bug
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/990337
Title:
BSNL USB Capitel EVDO not working after upgrade to 12.04
To manage notifications about this bug go
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/996664
Title:
Huawei E173 does not switch to modem
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 Ubuntu
Bu
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/99666
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/755342
Title:
Samsung Xcover 271 B2710 mass stor
Has anybody been able to test the "ReleaseDelay" parameter ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/979697
Title:
Modeswitching modem not working with some USB 3.0 host controllers
To manage
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://b
Hmm, after revisiting this whole thing, my conclusion is that if not
even the "eject" tool works on a USB3 port, the issue must be in the
kernel driver and/or hardware.
I will try to evoke this bug on my new machine.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I have suggested previously to have a look at libusb (0 and 1). Are
there any results yet?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/979697
Title:
Modeswitching modem not working in USB 3.0 port
This problem *may* be related to bug #990337 - driver loading failed
there because of an issue with finding "modprobe" on the system. AFAIK
this is limited to the C wrapper, so if it is the same problem it is
Ubuntu-only.
To be sure, we would need to see a log for the mode switching.
Bug reporter
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 Ubuntu
Bugs, which is subscribed
The problem is clear in the very first post:
...
Device not in "bind_list" yet, bind it now
modprobe not foundModule loader is (null)
Can't do anymore without module loader; get "modtools"!
driver binding failed
...
This is a problem of the C wrapper - maybe the MODPROBE macro is not
correct?
us
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
That's probably because the USB printer driver was loaded which in turn
means that at least the mode switch was successful.
To see in more detail what is happening when you re-plug the printer,
call the "dmesg" shell command afterwards.
For printing, you might have to ask at a different place; I
If I were you, I'd first use the unchanged Ubuntu packages for 12.04;
you can use the upstream source package as well but then you'll need
packages "libusb-dev" and "tcl" (or "jimtcl") for installation.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscr
O.K., I assume you have the "usb-modeswitch" and "usb-modeswitch-data"
package installed.
Now you have to do two things:
1. Edit "/lib/udev/rules.d/40-usb_modeswitch.rules" and add a line for
your device. There is one in there already for a printer with ID
03f0:002a; you can just copy it and cha
I did not see the bug reporter or any other HP owner contributing
his/her configuration.
The consequence is that we are stuck with the existing files for HP
devices' mode-switching. I can maintain usb_modeswitch upstream, but I
can't buy all that hardware for testing. So much for ranting.
To solv
Before doing the whole "sniff-on-the-MSWindows-driver routine", it may
be useful to try the known mode-switch data for a device family.
I suggest adapting the existing configuration (LaserJet P1102) to the
device IDs of the printer in question - and just see if it's working.
--
You received this
O.K., I released 20120531 with the fix applied.
Sorry again for the lapse of memory.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/894448
Title:
Unable to access USB storage of ZTE Blade Android ph
I'm deeply sorry to say I did not remember to apply the fix ...
Data package 20120529 has just been released - I am going to make the change
immediately and release 20120531.
Didier, I hope you did not repackage the new release yet ...
--
You received this bug notification because you are a mem
Looking at Akila's MM log, I see two possible issues.
1. There may be an offending command here:
[1317801779.197484] [mm-at-serial-port.c:298] debug_log(): (ttyUSB0):
--> 'AT+COPS=3,0;+COPS?'
After that command, there is no more answer from ttyUSB0.
2. Very close to that point there is an erro
Please be a little bit more specific. Why do you conclude that usb_modeswitch
is responsible for the connection problems?
Mind that the orignal bug was about the mass storage mode of the phone, not
about connecting issues.
Also, the committed fix will prevent *any* mode-switching action for
this
It might be a case of the modem not adhering to the standards. I
remember a similar problem with Huawei sticks, exposed when the 2.6.32
kernel started to enforce protocols more strictly.
Anyway, this is well over my head and should probably go to the "linux-
usb" mail list.
--
You received this
Unfortunately, you may be on your own then. Huawei software installs its own
mode switching program, regardless of what is present on the system. It may
switch the stick to a mode which is unsuitable for Network Manager (Huawei
modems have more than two different modes).
You can try to find this
So, did you install Mobile Partner from the stick or is there an
official Ubuntu package ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/991680
Title:
Huawei E220 and E1550 can't connect on Ubuntu 1
Hmm, it looks like your device has in fact switched to modem mode ...
It's not unusual for some devices to provide their "install storage"
again after the mode switching. I'm just wondering which program or
event is responsible for the switch.
In the dmesg output the mode switch process will show
If you compare the current log with this directory listing and the path
that udev provides (4-4:1.0) does not exist, then the hotplug system may
be to blame.
Could you post the end (starting from "new USB device") of the output
from the "dmesg" command, right after plugging the stick in ?
--
You
Can you check for the directory mentioned in the log (while stick
inserted) ?
What's the content of "/sys/bus/usb/devices" ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/991680
Title:
Huawei E220
Did you try the "eject" tool yet when on the 3.0 port?
# eject /dev/sr0
Is there a difference in the "dmesg" output if you plug into the 2.0
port?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/979697
This is not a problem with modem-manager. It looks like the device was
not mode-switched properly.
Please enable logging of usb_modeswitch; to do this, edit
"/etc/usb_modeswitch.conf". It tells you about the log destiantion.
** Package changed: modemmanager (Ubuntu) => usb-modeswitch (Ubuntu)
--
You might try the "ResetUSB=1" parameter. This will issue a reset command after
completing the message transfer.
Somewhat unsubtle and just a shot in the dark, but who knows?
I just hope we did not encounter an issue with the xhci driver ...
--
You received this bug notification because you are
I have encountered several cases lately where timing issues surfaced.
I'm wondering if this may be connected to the spreading of 3.0 ports.
If you want to test, add the "WaitBefore=" parameter to your custom
config file. The value is in seconds - I'd start with 8 or so,
decreasing it in case of su
It is possible to build with libusb-1 - if you have libusb-compat-0.1
...
Don't know why Ubuntu does not have it.
For specifics see:
http://libusb.org/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs
Re-addressing this issue after a busy while.
Your usb_modeswitch log from a successful switch is indicating that your
installation is using "libusb 0". This follows from the fact that the
name of the bound driver ("usb-storage") is reported. "libusb 1" is not
able to do this.
Can you try to compi
The only thing sticking out is the somewhat "non-mainstream" message
content. No other (ZTE) device is using this.
I'd suggest trying with the mainstream ZTE command (basically an EJECT):
- Extract the "19d2:0166" file from
/usr/share/usb_modeswitch/configPack.tar.gz
- Put it into /etc/usb_modes
Sorry, Mathieu, I tried entering "modem-manager" which was not accepted.
Darned hyphens ! :-)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/891307
Title:
usb_modeswitch does not recognize ZTE 19d2:
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
The setup of modems before and after switching can not be influenced by
usb_modeswitch. The device firmware is responsible for that. Did you do
a device update perhaps?
To disable mode switching temporarily and access the pseudo CD-ROM, you
can also set the "DisableSwitching" parameter in
/etc/usb
Mathieu is correct. The SCSI output will be given by default if you just
leave away the -I parameter.
Just make sure your device is not yet mode-switched at the moment you
run the command.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubunt
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
> There are the images with the terminal's output.
Next time you post any logs, I suggest you don't provide screenshots but
simple text files. You can mark and copy the content of a terminal
window similar to any text window, just use the "Edit" menu for copying
as the usual Ctrl-C shortcut will n
Please open a terminal window and run the command "lsusb" WITHOUT your stick
present. Then plug your stick in.
Again, run the command "lsusb". Note the line that was not there before. That
is your stick's identification.
Note the USB ID of it (example: "1234:89ab") and run the command "sudo
lsus
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/868034
Title:
Huawei E220 can't connect on Ubuntu 11.10
To manage notifications about this bug go to:
> 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 U
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
1 - 100 of 172 matches
Mail list logo
