ModemManager and generic USB hardware (was: Fatal flaw in the udev paradigm?)

[Oron Peled]

On Thursday 31 October 2013 12:00:10 Dan Williams wrote:
> .... If you're on a server, and that server does not
> have any "SMS me when you're down" functionality, then you may not want
> ModemManager installed there.

+1

But also in other cases, like the following:

 * Software/hardware developer use a Linux laptop
 * They remove ModemManager so it won't mess with their electronic
   hardware testing.
 * Later on, they are on the road and need something urgently.
 * No problem, we have GSM modem, but... it's not working...
 * No problem, we'll re-install ModemManager, but... we need a chicken
   for this egg (or maybe vice versa ;-)

All of this just begs for a global disable flag for ModemManager:
 * This should probably go into NetworkManager.
 * It should be a boolean runtime flag, e.g: some dbus property.
 * This way it could be exposed in UI (enable/disable modems).

>  But we'd also like to hear about devices
> that MM probes-but-shouldn't-probe so we can black/greylist them as
> appropriate.

While this will solve many problematic cases, it would still leave
a lot of unresolved cases:
 * Either permanently (because of broken hardware)
 * Or temporarily (until packages with updated graylist are installed).
   [yes, the admin may create something temporary in /etc/udev/rules.d
    but I'm talking from a *user* pov]

It looks like ModemManager should be able to pass some decision to the end
user.

Here is one possible model for doing this:

 * All *potential* modem devices (serial ports, known USB id's, etc.) that
   are reported to ModemManager build a list of "Possible modems".

 * However, ModemManager scan all this list *only if* a "scan_all_devices"
   property is "true" -- in this case, it behaves like today.

 * Even when this property is "false", the user would be able to call
   a new "ScanDevice(dev)" method to scan *a specific* device (from
   the "possible modems" list).

Combining the two changes with the suggested global disable flag, would allow
a UI (e.g: nm-applet) to provide an interface which is both easy to grasp
and highly flexible (IMHO):

 * With "modems" disabled -- everything is silent.

 * With "modems" enabled -- the user can see a list of devices:
   - The UI may optionally augment this list with some sysfs properties if
     they exist (e.g: idProduct for USB devices, or the strings from the
     USB hardware database, etc.) -- this extra info is public anyway and
     doesn't require any MM involvement, it's just a UI thingy.

   - If "scan_all_devices" is true, the UI may augment the list display
     during the scan by MM. E.g: gray out devices that haven't responded yet,
     show some progress for currently scanned device, display SIM information
     when MM read it, etc.)

   - OTOH, if "scan_all_devices" is false, the user may click a specific
     device from this list to start "ScanDevice(dev)" on it.

 * Optionally, the UI may implement further selection rules. For example:
   - Allow the user to "blacklist" specific devices in the UI.
   - This "blacklist" would be a UI list (i.e: client side).
   - The UI would simply "ScanDevice(dev)" all other devices, so MM wouldn't
     know/care about the extra granularity that was added by the UI.

Last, unrelated, suggested MM udev tweak:
 * A lot of USB modems have several USB interfaces which translates to several
   /dev/ttyUSB* etc.

 * Some of the drivers (e.g: ZTE) provide a way for udev rules to hint them
   about the preferred "MODEM" interface, e.g:

         ... ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_ZTE_PORT_TYPE_MODEM}="1"

 * Since there are so many "no-name/broken" USB modems out there, it would be
   nice if this provision could be re-factored so it would apply to any USB
   modem plugin (including the "generic" one):

         ... ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_PORT_TYPE_MODEM}="1"

Now I wait to see:
 A. If these ideas are just stupid and I don't understand anything about MM.
 B. Or they are OK, but MM people cannot be expected to implement any
    random nice idea suggested by "someone on the Internet"...

If it's B. -- please let me know and I'll try to see if I can prototype
something that may even function on some lucky days ;-)

Thanks,

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
"Microsoft: We make virii work!"