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