Originally reported at: https://bugzilla.gnome.org/show_bug.cgi?id=688213 The original bugreport in gnome.org has some very useful comments on the issue, which you should read if you're interested in this issue; e.g.: https://bugzilla.gnome.org/show_bug.cgi?id=688213#c23 The current logic to decide whether a TTY is to be probed by ModemManager goes more or less as follows: * Platform ports (real RS232 ports, if any) need to be explicitly Whitelisted if they should be probed by ModemManager. RS232 devices are no longer very much used by consumer users, but they are still very used in the industry. * TTY ports which are explicitly Blacklisted in ModemManager will never get probed. * TTY ports which are Greylisted in ModemManager will never get probed automatically; they will only get probed if explicitly requested to do so via a manual Scan() call. * Otherwise, the port will get probed. This strategy is not ideal, as new USB devices that expose TTYs will need to be explicitly blacklisted/greylisted in ModemManager so that they don't get probed. This issue may be especially relevant with e.g. serial screen-readers for people with disabilities; if MM takes over the TTY, even just for AT probing for some seconds, the main software wanting to use the screen-reader may break. There is of course other kind of devices affected (e.g. devboards with microcontrollers accessed via serial). Some of the solutions suggested in the original thread are specific to the cdc-acm device (e.g. checking capabilities reported by the driver in the kernel), but if a solution is to be found, I guess it should cover every possible driver exposing TTYs, not just one.
One of the possible solutions would be to explicitly Whitelist in ModemManager all known modem vendors. We probably have by now a very long list of known modem manufacturers (likely longer than that of non-modem TTYs), and adding all their VIDs in a single list shouldn't be a big issue. Now, this list could only apply for automatic probings (those done automatically by MM when new TTYs reported via udev). If a Scan() is executed by the user (e.g. "mmcli --scan-modems"), the probing could just ignore this list and probe all TTYs anyway. This would let us testing possible new VIDs to be added easily; if a user reports that a modem was previously supported and is no longer detected, we would directly ask to run a manual Scan() to see if the modem is detected in that case, and if so we would have a new VID to add. This new logic would not help if the non-modem device is actually developed by a manufacturer for which we whitelisted the VID; in that case we would still need to blacklist those. Plus, most new modems out there (e.g. all LTE-capable ones) really need either a specific plugin in MM (not the generic one) or a totally different control channel (e.g. QMI or MBIM). So, the possibility of losing support for AT+PPP modems that were previously handled by the generic plugin (i.e. those that would not get added in the new VID list) could really now be very low. Dan, what do you think?
I think a whitelist option is fine, but I certainly don't want to maintain it and I think it'll very quickly get out of date. However, as advocated by Jean-Christian de Rivaz on the systemd and modem-manager lists in the "use a specific device" thread, I'm OK to provide that as an option with MM if that user wants to use it themselves. So, what if there was a new tag like ID_MM_WHITELISTED on the USB device that users could set, and then Jean-Christian could write whatever udev rules he wanted to write to get there. That combined with a new command-line option like "--whitelist-generic" would cause MM to ignore any device that did not have ID_MM_WHITELISTED=1 set. I guess we could try to maintain a whitelist, but honestly that's a crap-ton of work that I don't want to do. I suspect the users who want a whitelist probably have a small number of modems they care about and are easily able to create the rules themselves.
Hi folks, I make a device that falls into the category being discussed here - a computer keyboard with a serial bootloader and a serial communications protocol. As far as I can tell, the ModemManager automatic probing causes the device to behave erratically. A similar thing happens with all AVR-based Arduino boards when they're probed by ModemManager. Because the keyboard is built to be user-programmable with Arduino, the "reboot to bootloader" signal is Arduino's standard "Connect to the serial port at 1200 bps and immediately close it." While this isn't what I might choose if I were building it myself, this is what Arduino does, so we're stuck with it. Typically, the advice I see is for the user to install custom udev rules or to remove ModemManager from their systems. Neither of these options are ideal recommendations for end users who just want to use a keyboard. As a device maker, is there anything I can do today that will stop currently deployed versions of ModemManager from attempting to probe my device's serial ports? I'm willing to mess with my USB descriptors or jump through other hoops Thanks!
Hey, > > I make a device that falls into the category being discussed here - a > computer keyboard with a serial bootloader and a serial communications > protocol. > > As far as I can tell, the ModemManager automatic probing causes the device > to behave erratically. A similar thing happens with all AVR-based Arduino > boards when they're probed by ModemManager. > > Because the keyboard is built to be user-programmable with Arduino, the > "reboot to bootloader" signal is Arduino's standard "Connect to the serial > port at 1200 bps and immediately close it." While this isn't what I might > choose if I were building it myself, this is what Arduino does, so we're > stuck with it. > > Typically, the advice I see is for the user to install custom udev rules or > to remove ModemManager from their systems. Neither of these options are > ideal recommendations for end users who just want to use a keyboard. > > As a device maker, is there anything I can do today that will stop currently > deployed versions of ModemManager from attempting to probe my device's > serial ports? I'm willing to mess with my USB descriptors or jump through > other hoops > I'm afraid there's not much you can do without also changing ModemManager in some way or the other. Right now the "hotfix" is to just let your users add a new udev rule in the blacklist file for your vid:pid, and also provide the same rule to us to include it right away. If you let us know what vid:pid to blacklist, I'll get it included in the stable releases happening this week.
Thanks so much for the quick reply, Aleksander. The VID is 0x1209. The two PIDs for our device are 0x2300 and 0x2301. Is there a doc that describes the probing process? I ought to be able to at least bullet proof against it a bit better.
(In reply to Jesse Vincent from comment #5) > Thanks so much for the quick reply, Aleksander. > > The VID is 0x1209. The two PIDs for our device are 0x2300 and 0x2301. > Added blacklist entry in git master, mm-1-6 and mm-1-4, see: https://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=650d2304259d767e8925d74221c262c020e1bfb0 > Is there a doc that describes the probing process? I ought to be able to at > least bullet proof against it a bit better. There is documentation regarding how the probing process assigns a device to a given ModemManager plugin: https://www.freedesktop.org/software/ModemManager/api/latest/ch02s02.html But I'm not sure there is anything saying how ModemManager skips probing devices. Anyway, that part is simple: * If a device is blacklisted with ID_MM_DEVICE_IGNORE, nothing from the device is probed. * If a device is greylisted with ID_MM_DEVICE_MANUAL_SCAN_ONLY (for USB RS232 adapters) the device is only probed on manually requested scans, never automatically. * Otherwise, the device is probed (if there is any TTY or cdc-wdm port to probe).
I currently work for an electronics manufacturer, and we've being hit by this bug on some of our TTY emulators (which, incidentally, don't have a public PID/VID yet). I've been pouring over the USB spec, and found a very interesting piece of info. The documentation for CDC devices ( http://www.usb.org/developers/docs/devclass_docs/CDC1.2_WMC1.1_012011.zip ) states that the field for the protocol interface tells whether the device supports AT commands or not. In other words, if you run `lsusb -v` and see this bit: bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) That means that the device is reporting "I understand AT commands". On the other hand, if the `lsusb` output looks like ... bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 0 ...that means the device reports that it doesn't understand AT commands. AFAIK, the possible values for bInterfaceProtocol in this case are as follows: 0x00 No protocol 0x01-0x06 AT command sets (V.250, GSM, 3GPP, etc) 0x07 Ethernet emulation 0x08-0xFD reserved 0xFE external protocol 0xFF vendor-specific As a colleague of mine pointed out, this can be written as a udev rule: SYBSUSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{bInterfaceProtocol}=="00", ENV{ID_MM_DEVICE_IGNORE}="1" This rule *should* work for all USB CDC ACM devices, as long as manufacturers take the effort to populate the bInterfaceProtocol field in their USB descriptors. If your device reports that it supports AT commands, ModemManager will probe it; if it doesn't, it won't get probed, and everybody should be happy. (as a side note, I agree with the comments at https://bugzilla.gnome.org/show_bug.cgi?id=688213#c23 )
> This rule *should* work for all USB CDC ACM devices, as long as > manufacturers take the effort to populate the bInterfaceProtocol field in > their USB descriptors. Yeah, but not all manufacturers do that, which is why we're still discussing about this issue :) While you're at it, could you please take some time to try to reproduce the problem with ModemManager built from git master and running with the "--filter-policy=STRICT" extra option? In the next MM 1.8 release we have added a strict policy based on some heuristics to decide whether a TTY is probed or not, and distributions will very likely start using it. This should completely avoid probing the TTYs of the device you're manufacturing without any other udev rule added. I know that rebuilding MM for this test may be lost time for you, but it would really help us to validate the implementation... If you need help on how to do and test the custom build, just email me privately and I'll guide you through the process.
I tested the "strict" filters in the current master branch (v1.7.0), and I can confirm that non-modem USB-CDC-ACM devices are not probed with AT commands. This happens as long as the USB device reports (via its descriptors) that it's *not* capable of understanding any kind of AT commands (see https://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=c4ea37fa02aaa0860f067062cbd315e3540aacce ).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/38.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.