[RFC] AT-capable ttyACM port heuristics are not perfect

[Aleksander Morgado]

Hey all,

>
> When using the "strict" filter in ModemManager, we try to use
> different heuristics to guess whether a device is a modem or not.
>
> One of the checks we do is looking at the exposed interfaces: if the
> device exposes one or more ttyACM ports that report themselves as "AT
> capable" (class=2/subclass=2/protocol=1), then we assume the device is
> a modem device and we perform port probing.
>
> Well, it looks like several Arduino devices expose ttyACM ports and
> advertise them as AT-capable even if they aren't. [1]
>
> Disabling the ttyACM AT-capable filter rule with the
> "MM_FILTER_RULE_TTY_ACM_INTERFACE=0" environment variable makes the
> Arduino device no longer probed because they're not accepted by any
> other of the heuristics. [2]
>
> Should we remove the ttyACM AT-capable filter rule? If we do this and
> there are modems out there that expose exclusively ttyACM ports (and
> no NET port) then we would not probe them any more. I'm not sure I can
> think of any modem that *only* exposes ttyACM ports, except for
> "special" setups like a MC7455 running in a system that doesn't have
> QMI or MBIM kernel drivers available. Still, this may be a usecase for
> some people, don't know.
>
> Or should we keep a new short blacklist that would apply also in
> "strict" filter mode?
>
> I'm tempted to write and maintain the new short blacklist, because I'd
> also like to remove completely the old greylist/blacklists at some
> point in the future (1.12?).  What do you all think?
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930264
> [2] https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/127
>

This is the approach I'm going to suggest to avoid this issue, comments welcome:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/143

With the change to ignore ttyACM ports with protocol=1, we would be
ignoring all Arduino devices that are wrongly claiming AT protocol
support. Only this protocol=1 value is being ignored because that is
the value that was used as default in Arduino.

What do you all think?

-- 
Aleksander
https://aleksander.es