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

Aleksander Morgado aleksander at aleksander.es
Tue Aug 27 11:53:51 UTC 2019

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:

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?


More information about the ModemManager-devel mailing list