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

[Aleksander Morgado]

Hey,

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

-- 
Aleksander
https://aleksander.es