Debian discussion to disable automatic TTY probing

[Dan Williams]

On Thu, 2017-09-28 at 21:08 +0200, Aleksander Morgado wrote:
> > > Got told today that Debian is discussing whether to disable
> > > automatic
> > > probing of TTY devices in MM, some links:
> > > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877024
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839
> > > 
> > > This is the ModemManager bug report about this issue, for
> > > reference:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=85007
> > 
> > The problem cases here are:
> > 
> > 1) generic USB/serial converters
> > - we can't easily handle this one
> > 2) cdc-acm devices
> > - we could theoretically only auto-probe ttys that specify
> > class=2/subclass=2/protocol=1 (Communications/Abstract/AT-
> > commands),
> > but I'm sure there are some devices that don't adhere to the specs
> > well
> > 3) modems that haven't been added to kernel drivers yet
> > - can't do much here, and there are probably a lot of these
> > especially
> > with older kernels
> > 4) platform devices
> > - we already graylist these
> > 
> > For almost all others you can key off the kernel driver type.  So I
> > guess if Debian wants greylist everything, but then they'll need to
> > come up with a "probe my modem!" tool with a UI that doesn't
> > suck.  And
> > there's the problem...
> > 
> 
> I really believe we should (try to) solve this ourselves. If we add
> heuristics to try to detect whether something is a modem, I'm sure
> we're going to find corner cases, then we either add more heuristics
> or a whitelist... The key thing is to have a very good initial set of
> heuristics, and given that most new modems aren't TTY-only, we should
> probably not be very dramatic about this... probably.
> 
> How about:
>  * If device is manually tagged by the user as a modem, go on and we
> probe the tty.
>  * If device has a net port in addition to tty (QMI, MBIM, Option
> HSO,
> Sierra Direct IP, u-blox, most Telit...), it's a modem and we probe
> the tty.
>  * If kernel driver of the TTY is option/sierra/qcserial, it's a
> modem
> and we probe the tty.
>  * If kernel driver is cdc-acm and class=2/subclass=2/protocol=1
> (Communications/Abstract/AT-commands), it's a modem and we probe the
> tty.
>  * If vid is a known modem vendor (e.g. huawei, zte, sierra, u-blox,
> telit....), it's a modem and we probe the tty.
>  * otherwise, we don't probe it automatically, but we expose an API
> in
> DBus that could allow the user request a device probe manually for
> that specific device.
> 
> Probably the vid-based filter is also not perfect as those
> manufacturers may have non-modem devices with TTYs, but hey, we would
> anyway be probing those right now anyway.
> 
> Also, not saying there should be a UI to handle the suggested new
> DBus
> API in e.g. gnome-shell, but definitely something that could be
> triggered from mmcli or so.
> 
> Anything we do in MM upstream to try to avoid the autoprobing is
> better than just blindly ignoring all TTYs, which is what Ian is
> suggesting for now, I believe.

Well, they will figure out pretty quickly that solution kinda sucks for
modem users, and simply makes life worse for one group while making it
better than another.  But it's their distro and they get to make the
judgements about which users are more important.

Meanwhile, in the actually constructive camp, I think your proposal is
likely the best way to go and I think you cover the cases pretty well.

The only hole in your plan I could come up with is other bus types like
PCMCIA and PCI, for which I have a couple (admittedly old) example
modems like the Sierra 850/860 and Option Nozomi.  We need to make sure
that we take different bus types into account when making these rules,
so that we don't regress in auto-probing those devices.

Might also be worth scraping usb_modeswitch data to find known VID/PID
that aren't in the existing kernel drivers, if any.

> The question would also be whether this is something we want to do as
> default from now on (and therefore we ignore the blacklist/greylist
> we've built until now) or if this is something we should keep in
> parallel with the current logic and let the user/distribution decide.

Obviously there's a possibility that we'll cause regressions for users
of some modems if we just enable by default.  I think those will likely
be users who have modems that aren't yet added to kernel drivers (which
are often users of older kernels) but those people will have had to do
manual hacking to force-bind usbserial or option or something.

There's also usb_modeswitch's historic behavior of force-binding option
which I think they've disabled in the last year, but users of older
versions might be affected by a change to MM.

I guess I'd say if the code/rules changes are large, then there is more
of an argument to just cut over to the new code.  If the changes are
smaller, then maybe we keep them in parallel for a while until we find
out the impact.

Dan