Hi,

since a while, ModemManager is using the new "strict" filter policy.
Rather than probing all serial ports that are not blacklisted (which
causes problems with serial devices that do not like to be probed), it
now uses more specific rules about what devices are likely to be modems
and does not probe any others.

However, this strict policy does *not* use the blacklist (configured
through udev rules), which I believe is problematic.

This problem particularly surfaces when using Arduino serial devices.
These development boards enumerate as TTY ACM USB devices, which cause
the kernel to automatically create serial ports for them. However, in
their USB descriptors, these devices advertise support for AT commands
(class=2/subclass=2/protocol=1), which triggers the MM
FILTER_RULE_TTY_ACM_INTERFACE and makes it probe these devices.

Of course, the actual problem in this case is that these devices
misadvertise themselves in their USB descriptor. I've raised this issue
in the Arduino community [1] and hopefully this will be fixed in the
future, but this will not help for existing devices (whose firmware is
not automatically or easily updated). This means that there are a lot of
Arduino devices out there which are broken by the switch to strict.

Previously, these devices were handled by the blacklist, but now they
are again probed when they should not. I suspect that there might be
other devices that have a similar fate. Also, users (such as myself)
might have collected some udev rules with blacklists over time, which
now unexpectedly stop working.

It seems that disabling the blacklist in strict mode is not an oversight
from upstream, since they also offer a "paranoid" mode which is equal to
"strict" mode but with the blacklist and greylist (manual scan only)
enabled.

A potential fix is to use the paranoid policy rather than the strict
policy, or to explicitly enable the blacklist and/or greylist on top of
the strict policy. I tried the latter, which indeed prevents MM from
probing my Arduinos. I did this:

  $ cat /etc/systemd/system/ModemManager.service.d/override.conf
  [Service]
  Environment="MM_FILTER_RULE_TTY_BLACKLIST=1"

Note that upstream discourages using the blacklists in their
documentation:

However, I've raised this same issue upstream [2], asking them to reconsider
this position.


Since this issue is a regression (Stretch still has a working blacklist,
but the Buster version uses the swtrict policy), it would make sense to
me to still make this change in Buster, if the freeze policy allows
this.

[1]: https://github.com/arduino/ArduinoCore-avr/pull/92
[2]: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/127

Gr.

Matthijs

(Note that I'm running Ubuntu on this machine, but reporting this to
Debian since that's where I believe this should be fixed)

I am not yet sure what to do with this issue.

The Arduino is saying that it has an AT-capable ttyACM port, so ModemManager tries to use the port. I'd like to improve the heuristics to detect this without falling back to the blacklist, but not sure yet how to reliable do that. Ideally, the Arduino shouldn't say that its ttyACM is AT-capable...

Any suggestion on how to improve the heuristics, without falling back to the blacklist, would be appreciated. Maybe we should no longer try to use devices that expose one single ttyACM port even if the ports are reported as AT-capable?

Hi,

I've hit this problem with a DMR radio that uses a USB programming
cable. It presents as a ttyACM device, which is snapped up by
ModemManager. These are not the most robust interfaces and I could
easily see radios being bricked by accepting an "upload" of
firmware/config while ModemManager is probing.

(More worryingly, if this happens with amateur radio soundcard
interfaces which commonly use homemade USB serial cables to control
transmission, it could cause the radio to transmit without warning,
possibly outside the licensed band and certainly without identifying the
station, which would cause a criminal offence to be committed.)

The second of these cases is going to be harder to protect against than
the first, but it would be nice if ModemManager didn't just assume
responsibility for any serial USB device that happens to be attached.

For the DMR radio, I have a udev rule that I included in the dmrconfig
package (not yet uploaded) that looks like:

ATTRS{idVendor}=="28e9" ATTRS{idProduct}=="018a",
ENV{ID_MM_DEVICE_IGNORE}="1"

I'm happy to maintain the list of DMR radios to ignore in that package,
but ModemManager is helpfully ignoring the rules.

Should I just suggest users disable ModemManager? What is the workaround
for this?

Thanks,
Iain.

The ID_MM_DEVICE_IGNORE udev tag is being ignored in strict filter mode, I'm trying to change that in this MR for the next MM release:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/138

Iain, could you let me know the full lsusb -v output of that specific DMR radio? I need to understand whether the device is wrongly claiming AT protocol support in the ttyACM interface or not.

And this is the suggested change to avoid the issue with the Arduinos wrongly claiming AT protocol support:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/143

This issue should be hopefully solved in ModemManager 1.10.6 after adding several new heuristics to the "strict" filter mode.
Also, the logic behind ID_MM_DEVICE_IGNORE was updated and this udev tag is now applicable in all filter modes (including "strict") and for all device types (not only TTYs).

MM 1.10.6 release notes:
https://lists.freedesktop.org/archives/modemmanager-devel/2019-September/007424.html

Hi,

I think from the output, the answer is yes.

Thanks,
Iain.

---


Bus 005 Device 006: ID 28e9:018a GD32Microelectronics GD32 Virtual
ComPort in FS Mode
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x28e9
  idProduct          0x018a
  bcdDevice            1.00
  iManufacturer           1
  iProduct                2
  iSerial                 3
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0043
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              10
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0