desktop-packages team mailing list archive

["H.-R. Oberhage" <oberhage@xxxxxxxxxxxxxxxxxxxxx>]

Public bug reported:

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)

** Affects: modemmanager (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: amd64 apport-bug wily

-- 
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:
  New

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