Make an E173s-1 [12d1:14d1] Huawei usb-UMTS-stick work properly

[H.-R. Oberhage]

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)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.