Debian discussion to disable automatic TTY probing

[Aleksander Morgado]

>> 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.

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.

-- 
Aleksander
https://aleksander.es