touch-packages team mailing list archive

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

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.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded 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