huawei plugin not used on for USB webstick E173s-1 [usb: 12d1:14d1/14c9]

Bug #1534678 reported by H.-R. Oberhage
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
modemmanager (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

Starting with Ubuntu 15.10 (wily) my USB webstick does not work any longer. It used to work with Ubuntu for several previous versions.

My stick is a Huawei E173s-1 with a usb-vendor/-product id 12d1:14d1 before and 12d1:14c9 after 'modeswitch'.
The - or at least one - reason for not working any longer is, that modemmanager uses the 'generic' plugin, instead of the 'huawei' one. The behaviour does not depend on my software-configuration. It happens from a plain 15.10 live-version up to my installed up-to-date-patched notebook (amd64 architecture, but from what's written below, I don't think it is architecture-specific.)

Using the --debug - option from 'modemmanager' and tracing with gdb after loading the -gdb .deb-package, I came to the following conclusions:
The 'huawei' plugin is filtered out in the 'pre' phase, already, the reason being vendor-/product-id mismatch.
The vendor-/product-ids 'detected' instead by the "get_device_ids"-function in "mm-device.c" are 8068:3b34 for the Intel USB 2 ehci host controller, which actually is a 'child'(??) device of the stick. The problem arises, when checking the first of the ttyUSBx (x being 0, 1, 2, and 3) devices for the stick in "find_physical_device", which calls "get_device_ids" later on.

As far as I can tell, the error originates in the "g_udev_device_get_property" call for ID_VENDOR_ID and ID_MODEL_ID in the 'lib_gudev' library, which returns the false ids. It might even come from 'udev'. A 'udevadm info' display of the USB-tree shows the correct(!) vendor-/product-ids for the whole tree, though!

Once the 'generic' plugin has been (wrongly) chosen, the debug info shows the correct ids (12d1:14c9) for the 'selected' device (again). It however won't configure my stick, telling me that the device is not capable of taking ipv4/ipv6 information.

So far for the facts.

Now allow me some speculation and a proposal:
I would assume, that the whole mess comes from the very faulty, buggy and problematic 'systemd', which controls 'udev' in 'wily'. The "lib_gudev" is also a split-off part from it. With 'systemd' it is no longer possible to manually interfere with wrong or questionable decisions, as could be done with standard 'udev' via rules or 'sys-v-init' by changing (ba)sh-scripts.

Now my proposal (and wish) would be to install some mechanism in 'modemmanager' to overwrite/force a plugin selection from the outside, as is e.g. done for selecting ports with the "77-mm-huawei-net-port-types.rules" (ID_MM_HUAWEI_MODEM_PORT and similar). Any other mechanism would be welcome, too. With this, one could correct any poor choice made by a binary program or library. And it would not hit ordinary or inexperienced users. Thank you.

And thanks for the good work!

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: modemmanager 1.4.10-1ubuntu2
ProcVersionSignature: Ubuntu 4.2.0-23.28-generic 4.2.6
Uname: Linux 4.2.0-23-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.19.1-0ubuntu5
Architecture: amd64
CurrentDesktop: Unity
Date: Fri Jan 15 17:37:09 2016
InstallationDate: Installed on 2015-07-08 (191 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
SourcePackage: modemmanager
UpgradeStatus: Upgraded to wily on 2015-10-23 (84 days ago)

Revision history for this message
H.-R. Oberhage (oberhage) wrote :
Revision history for this message
H.-R. Oberhage (oberhage) wrote :

I can now confirm my analysis of the bug! And I got a new and unpleaseant surprise, too.

First I compiled a version of modemmanager (1.4.10) where the wrongly returned pci-id 8068:3b34 is swapped to the correct usb-id 12d1:14c9 in "get_device_ids". This is just a hack, of course, no solution. Now the 'huawei' plugin is used instead of the 'generic' one and all seems well. Remember, the whole thing used to work in Ubuntu 15.04 and before!

But now the NetworkManager complains with an odd message:
NetworkManager[1108]: <warn> (ttyUSB2): Failed to connect 'Vodafone WebSessions': Connection requested both IPv4 and IPv6 but dual-stack addressing is unsupported by the modem.
And although it is marked as a warning, it makes a network connection impossible:
NetworkManager[1108]: <info> (ttyUSB2): device state change: prepare -> failed (reason 'modem-init-failed') [40 120 28]

Since the capabilities come from the modemmanager I still think, here is the right place to begin the repair.
(From my previous (working!) connections I do know, that IPv4 will be sufficient, but I find no way to signal this to the NetworkManager!)

Any usefull advice will be welcome. Thanks.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in modemmanager (Ubuntu):
status: New → Confirmed
Revision history for this message
Saverio Miroddi (64kramsystem) wrote :

Confirmed for Huawei K3772, which was working on 15.04 and previous versions.

Revision history for this message
Alberto Salvia Novella (es20490446e) wrote :

Look if bug #1539348 is related.

Changed in modemmanager (Ubuntu):
importance: Undecided → Medium
Revision history for this message
H.-R. Oberhage (oberhage) wrote :

You seem to be correct, bug #1539348 describes exactly what happens to the IDs. I haven't yet checked for the "udevadm info" of the device (only), just for the whole tree. In the latter case, it is ok, but this is also the case for bug #1539348!

What bug #1539348 doesn't touch nor resolves is the problem of the "dual stack" IPv4/v6 error.

Thanks for paying so close an attention.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.