[RFC] Probing ttys by default

[Ben Chan]

On Fri, Mar 21, 2014 at 9:23 AM, Dan Williams <dcbw at redhat.com> wrote:
>
> On Fri, 2014-03-21 at 14:51 +0100, Lars Knudsen wrote:
> > If we take a step back and think how users will be best served by the
> > mechanism, I think there are several things we could consider as components:
> >
> > *  Could ModemManager perhaps wait X seconds before trying to grab a device
> > (allowing others to have "first pick")?
>
> This doesn't play well with users plugging in a modem and then waiting
> for it to appear on the system.  It's already long enough with
> modeswitch and probing.  I believe most of the problems we have are
> already adequately handled by the existing blacklisting and greylisting
> that MM does via udev rules.
>
> > *  Could it be possible that if someone plugs in a modem, there may (most
> > often) be so big human interaction actions already happening that an
> > interactive mode - potentially with a "remember decision" functionality
> > would be prefectly fine.  It's very seldom that a modem just does a
> > plug'n'play and connect without at least some interaction.
>
> This could be possible, but I don't believe it provides a great user
> experience.  Many devices are plug & play these days, or at least have
> the capability to be so, and we'd really like to be able to
> auto-provision these devices.  Furthermore, CDMA-only devices don't need
> much provisioning at all (eg, no APN required) and they are pretty much
> ready-to-go.  We want to move in the direction of *less* heavy
> user-interaction, not more.
>
> We also don't want the Windows-style behavior of every time you plug a
> modem into a different USB port, it gets re-detected and drivers
> re-installed, so mechanisms that would "remember" details about the
> device and save them later wouldn't be good either.
>
> > *  (already mentioned) - CDC descriptors to be used for detection - at
> > least having a combination that knowledgable developers can use to 100%
> > tell ModemManager to either white- or blacklist on the fly?
>
> If drivers provide hints, like you've suggested, this would improve the
> situation.  However, the problem is with devices that do not conform to
> the specifications; those devices are out there and must be supported as
> well.  One solution like this would be to have MM automatically greylist
> any cdc-acm device that does not appear to be a modem, though we'd have
> to do this carefully to avoid breaking existing devices that don't
> follow the specs.
>
> Dan
>

Second Dan and Bjørn's comment, modems don't necessarily follow the
CDC spec. I've encountered modems that didn't mark bmCapabilities
correctly, and wouldn't be too surprised that it's more a norm than an
exception. As I don't know how many legacy modems (especially 3G
dongles) that don't follow the spec, I'd be more cautious about the
blacklist approach. Instead of relying on bmCapabilities or
bInterfaceProtocol, a simpler approach may be to blacklist or
whitelist devices by USB vendor ID.

Major modem vendors would at least put their vendor ID correctly, so
we may ignore bmCapabilities for them. For other vendor IDs, we may
take bmCapabilities as a hint more seriously.