Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: modemmanager (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to modemmanager in Ubuntu.
https://bugs.launchpad.net/bugs/1176042
Title:
Make an E173s-1 [12d1:14d1] Huawei usb-UMTS-stick work properly
Status in “modemmanager” package in Ubuntu:
Confirmed
Bug description:
Dear package-management,
I would like to get a Huawei USB-UMTS-stick to work now and
persistently in future releases and avoid a kernel stop/crash at the
same time.
My stick is a "ProSieben" (delivery company), Vodafone (UMTS-, IP-
provider, websession-connection) from Huawei (manufacturer) with the
label E173s (E173s-1 on closer inspection) on it and with the USB-ids
12d1:14d1 before and 12d1:14c9 after the "usb-modeswitch" command.
The impact is most likely a broader one, at least for the Huawei
family, as its solution needs all the changes made for the "E173"
within the kernel (modules: option.ko (in usb/serial) and qmi_wwan.ko
(in net/usb)) not to long ago and additional ones in modemmanager.
With the modifcations described, "my" stick runs, so bear with me,
when I get a little more detailed at the start.
With a 'bare bones' "raring ringtail"-Ubuntu, when you plug the stick
in, it will after a little while (about 2 minutes) crash Ubuntu in
such a way, that only a hard switch-off of the device will help. The
reason is, that USB-port 1 (numbering starts with 0) will get a USB
tty device (/dev/ttyUSB3 in my case), and as soon as option.ko and
following that usb_wwan.ko tries to operate that device, its "queue"
will fill up and finally hang the kernel. For my stick, after the usb-
modeswitch the (USB-)ports are labeled (GETPORTS-lookup- with SETPORT
?-arrangement-command): (USB-0) NDIS, (USB-1) "7", (USB-2) PCSC,
(USB-3) DIAG. Here "7" means the MS-Windows-7 NDIS mode, and an "MDM"
label is missing, but "NDIS" takes its role. When "option" gets hold,
it will in sequence name the USB-ports USB-0 /dev/ttyUSB0, USB-2
/dev/ttyUSB1, USB-3 /dev/ttyUSB2 and when it gets the chance USB-1
/dev/ttyUSB3, which will then run havoc (see above). So in the first
place, by introducing the same blacklisting as exists now for "E173"
in "option.ko" for this stick - i.e. blacklisting
(net_intf1_blacklist) "interface-1" - and adding an entry in
"qmi_wwan.ko" for it just like for "E173", a device /dev/ttyUSB3 won't
be generated.
From that moment on, there will be no more kernel stop/crash.
But it still doesn't work! This is where "modemmanager" comes into
play: Because there is no "MDM"-entry, it will assign /dev/ttyUSB0
(ok!) and /dev/ttyUSB2 (no so good!) as modem devices. Now when it
comes to connecting to the net it will link /dev/ttyUSB2 to the
starting pppd (/dev/ttyUSB2 <-> pppd), which will not succeed! It
should have been /dev/ttyUSB0! So "NDIS' is the port to choose, here,
instead of the missing modem. When you add "NDIS" in addition to "MDM"
- as has been done in a PPA for "quantal" [modemmanager_0.6.0.0
.really-0ubuntu2~fix.lp1057186ubuntu1+168~quantal1(_i386.deb)] -
/dev/ttyUSB0 and /dev/ttyUSB2 will again be claimed for 'modem' by
modemmanager, but during the connection-phase /dev/ttyUSB0 (=USB-port
0) will be used and pppd succeeds. For this, just the source-code for
"libmm-plugin-huawei.so" has to be adapted.
The problem isn't really new for "raring", but happened in midtime of
"quantal", when the "E173"-kernel-changes were introduced. But in
"quantal" there were older kernels, that still worked, and the "PPA-
modemmanager"-version. Now for "raring", no kernel works, and
"modemmanager" is also newer - and I have seen no adaptation for it,
yet. So may be it's time to fix this thing once and for all.
My assumption is, that there are (many) more - at least Huawei -
devices affected by that "queue"-phenomenon, not just "mine"
[12d1:14d1 -> 14c9].
Should I have been unclear, should you need any additional information
or have a question, just contact me. I'll do what I can to fix this
thing.
By the way, can you arrange for the necessary kernel-fixes to be made,
too? You certainly have a better connection than me to the people
responsible. That would be nice.
Thanks for the help!
ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: modemmanager 0.6.0.0.really-0ubuntu5 [modified:
usr/lib/ModemManager/libmm-plugin-huawei.so]
ProcVersionSignature: Ubuntu 3.8.0-19.30-generic 3.8.8
Uname: Linux 3.8.0-19-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 2.9.2-0ubuntu8
Architecture: i386
Date: Fri May 3 15:31:06 2013
InstallationDate: Installed on 2011-03-05 (789 days ago)
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007.1)
MarkForUpload: True
SourcePackage: modemmanager
UpgradeStatus: Upgraded to raring on 2013-04-26 (7 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1176042/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
