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. -- 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/1534678 Title: huawei plugin not used on for USB webstick E173s-1 [usb: 12d1:14d1/14c9] Status in modemmanager package in Ubuntu: Confirmed 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1534678/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
