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
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
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,
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:
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
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.
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
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.
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
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
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.
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
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
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
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
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.
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
@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
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
@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.
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
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
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
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
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
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
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.
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
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,
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
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
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 E3531 HSPA+ USB Stick &quo
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
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:
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.
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
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.
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 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 the SCSI
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
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 than
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:
*** 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.
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):
--
# Huawei
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.
--
You
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
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
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 which
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
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.
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
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
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
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 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
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
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.
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
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,
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
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?
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
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
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
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 change
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 subscribed
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
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
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
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
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?CR'
After that command, there is no more answer from ttyUSB0.
2. Very close to that point there is an
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
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
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
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
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
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
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
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
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 compile
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.
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=n parameter to your custom
config file. The value is in seconds - I'd start with 8 or so,
decreasing it in case of
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
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)
--
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
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
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
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
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
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)
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
lsusb -v
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 not
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
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
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
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
1 - 100 of 172 matches
Mail list logo
