Public bug reported:
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)
** Affects: modemmanager (Ubuntu)
Importance: Undecided
Status: New
** Tags: apport-bug i386 raring
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1176042
Title:
Make an E173s-1 [12d1:14d1] Huawei usb-UMTS-stick work properly
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1176042/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
