summaryrefslogtreecommitdiff
path: root/src/mm-filter.c
AgeCommit message (Collapse)AuthorFilesLines
2021-06-16filter: remove support for TTY blacklist, TTY greylist and TTY default allowedAleksander Morgado1-33/+3
These lists were used in the corresponding TTY_BLACKLIST and TTY_MANUAL_SCAN_ONLY filter rules, in the LEGACY and PARANOID filter types, which are no longer supported. The DEFAULT_ALLOWED filter rule made sense only in the LEGACY filter type, and therefore it is also now removed, leaving the DEFAULT_FORBIDDEN fallback rule exclusively. In other words, there is now no way to ask ModemManager to implicitly allow TTY ports; the only way to do that is by explicit making the TTY ports fall in one filter rule that would allow them.
2021-04-21filter: Add wwan port devicesLoic Poulain1-0/+8
Allow WWAN control ports. Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
2021-04-14filter: add filter for QRTR devicesAndrew Lassalle1-0/+10
Add support for devices using the subsystem "qrtr".
2021-02-06filter: add missing reference to rpmsg filterAleksander Morgado1-0/+1
2020-11-20core: new 'rpmsg' subsystemAleksander Morgado1-0/+7
Most older Qualcomm SoCs (e.g. MSM8916, MSM8974, ...) communicate with the integrated modem via shared memory (SMD channels). This is similar to QRTR on newer SoCs, but without the "network" layer. In fact, the older SoCs also have QRTR, but the modem QMI services are not exposed there. The mainline Linux kernel exposes SMD channels via the "remote processor messaging bus" (rpmsg). Through special IOCTL calls it is possible to create a char device for a rpmsg/SMD channel. We can then use these to send QMI/AT messages to the modem, much like the ordinary serial char devices when using a Qualcomm modem through USB. This commit introduces support for the new 'rpmsg' subsystem, which allows exporting QMI-capable and AT-capable ports. By default NO rpmsg port is flagged as candidate, it is assumed that the plugin adding support for the rpmsg subsystem will add specific rules to do so (e.g. so that non-modem ports are explicitly not flagged as candidate). All rpmsg ports will be probed for AT or QMI capabilities, unless explicit port type hints (e.g. ID_MM_PORT_TYPE_QMI or ID_MM_PORT_TYPE_AT_PRIMARY) are set. These changes are highly based on the initial integration work done by Stephan Gerhold <stephan@gerhold.net> in postmarketOS, see: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/363
2020-11-13core: stop monitoring the 'usb' subsystemAleksander Morgado1-1/+1
Back in Linux < 3.6 days, the cdc-wdm ports exposed by the QMI driver were flagged as owned by the 'usb' subsystem. That changed in 3.6 when the subsystem was renamed to 'usbmisc': https://mail.gnome.org/archives/networkmanager-list/2012-June/msg00125.html This patch removes all monitoring of the 'usb' subsystem completely, which is anyway a valid subsystem but for which we shouldn't need any special handling. Right now, with newer kernels, we were using that monitoring exclusively to get notified of full USB device remove events, which is really not required as we already process the port removals one by one. We simplify the logic everywhere that attempted to match either the 'usb' or 'usbmisc' subsystems, and we no longer require the explicit checks for the port name being named 'cdc-wdm[0-9]*' in the code, as that is already taken care of by the ID_MM_CANDIDATE udev tag rule.
2020-11-06filter: simplify CDC_WDM rule to a subsystem-only USBMISC checkAleksander Morgado1-5/+4
This is not just a rename of the rule, we also now avoid doing an explicit check on the port name as well, and we rely on subsystem checks only; i.e. the same logic applied for net ports. The port candidate rules already do a 'cdc-wdm*' device name check so it shouldn't be a big deal.
2020-06-04filter: setup automatic per-vid checks in the plugin whitelistAleksander Morgado1-0/+37
Until now, the plugin whitelist rule in the filter would only handle those plugins that require specific udev tags, and those that had explicit full vid:pid pairs. This update makes a new implicit automatic whitelist for all devices that match any of the vids managed by the different plugins. Looking at the current list of devices in the blacklist and greylist maintained by ModemManager, there are no devices falling under the list of supported plugin vids that would need to be blacklisted; except for u-blox GPS modules: huawei -> 0x12d1 -> None in blacklist/greylist thuraya -> 0x1a26 -> None in blacklist/greylist telit -> 0x1bc7 -> None in blacklist/greylist dLink -> 0x2001 -> None in blacklist/greylist wavecom -> 0x114f -> None in blacklist/greylist x22x -> 0x1bbb,0x0b3c -> None in blacklist/greylist anydata -> 0x16d5 -> None in blacklist/greylist quectel -> 0x2c7c -> None in blacklist/greylist haier -> 0x201e -> None in blacklist/greylist novatel -> 0x1410 -> None in blacklist/greylist dell -> 0x413c -> None in blacklist/greylist option -> 0x0af0,0x1931 -> None in blacklist/greylist nokia -> 0x0421 -> None in blacklist/greylist cinterion -> 0x1e2d,0x0681 -> None in blacklist/greylist simtech -> 0x1e0e -> None in blacklist/greylist iridium -> 0x1edd -> None in blacklist/greylist pantech -> 0x106c -> None in blacklist/greylist longcheer -> 0x1c9e,0x1bbb -> None in blacklist/greylist linktop -> 0x230d -> None in blacklist/greylist sierra -> 0x1199 -> None in blacklist/greylist ublox -> 0x1546 -------------> GPS chips blacklisted !!!!! foxconn -> 0x0489 -> None in blacklist/greylist broadmobi -> 0x2020 -> None in blacklist/greylist fibocom -> 0x2cb7 -> None in blacklist/greylist tplink -> 0x2357 -> None in blacklist/greylist zte -> 0x19d2 -> None in blacklist/greylist The rules used to blacklist the u-blox GPS chips have already been moved to the u-blox plugin itself, and now they use the broader ID_MM_DEVICE_IGNORE tag that applies in all filter modes.
2020-04-08filter: port to use object loggingAleksander Morgado1-38/+55
2019-09-11filter: update plugin whitelist logic to use 'allowed product ids'Aleksander Morgado1-2/+49
Several plugins define the specific device vid:pid pairs they support. Let's use this information as a direct indication that ModemManager can probe the devices.
2019-09-11filter: require >1 port in devices with AT-capable ttyACMsAleksander Morgado1-15/+44
Instead of blindly allowing to be probed all ttyACM ports that report them as AT-capable, we will now instead forbid all ttyACM ports that don't report themselves as AT-capable. Also, require the modem to expose other additional ports (of any kind usable by ModemManager) in addition to the AT-capable ttyACM port. This update should avoid automatically probing Arduino devices that wrongly report their exposed single ttyACM port as AT-capable. https://github.com/arduino/ArduinoCore-avr/pull/92 https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/140 https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/127 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930264
2019-09-06filter: new plugin whitelist logicAleksander Morgado1-1/+48
Several plugins define specific udev tags that must be available in the device in order for the plugins to use them. Let's use these tags as a direct indication that ModemManager can probe the devices. In particular, this change would make all Ericsson MBM modems probed right away also in STRICT filter mode, without needing to check the ttyACM interface type or the available net ports.
2019-08-29udev: remove ID_MM_PLATFORM_DRIVER_PROBE tagAleksander Morgado1-6/+2
This tag is completely redundant because users can whitelist the platform TTY ports to use with the more generic ID_MM_DEVICE_PROCESS tag, which is part of the explicit whitelist filter rule.
2019-08-29udev: rename ID_MM_DEVICE_MANUAL_SCAN_ONLY to ID_MM_TTY_MANUAL_SCAN_ONLYAleksander Morgado1-2/+2
The udev tag that allows flagging devices that MAY be modems (e.g. USB<->RS232 adapters) is only applicable to TTY devices, so explicitly specify that in the tag name as well.
2019-08-29udev: repurpose ID_MM_DEVICE_IGNORE and new MM_FILTER_RULE_EXPLICIT_BLACKLISTAleksander Morgado1-2/+10
Until now the ID_MM_DEVICE_IGNORE udev tag was being used in the internal blacklist of devices shipped by ModemManager when running in either DEFAULT or PARANOID filter modes. The name of the tag is extremely misleading because it doesn't really make the full device be ignored, the tag only applied to TTY ports. This commit repurposes the tag so that it applies to ANY kind of port (e.g. TTY, NET, cdc-wdm...) and also to any kind of filter type (i.e. also applicable in STRICT mode). The internal blacklist shipped by ModemManager, which should NOT be used in STRICT mode, uses a new tag name, ID_MM_TTY_BLACKLIST. The new ID_MM_DEVICE_IGNORE tag is therefore much more usable and its name is really meaningful. If there are users or third-party projects adding their own udev rules with the ID_MM_DEVICE_IGNORE tag name, they should have no problem as the new rule is more restrictive than the old one.
2018-09-25udev: define all generic tags as symbolsAleksander Morgado1-5/+8
This prevents errors due to nasty typos in the strings. We define all symbols in a single header file that is NOT considered part of the API, as there is no need for MM clients to know about these tags code-wise. These tags are only meaningful when associated to devices in udev. Information of each tag is included in the general API documentation. https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/88
2018-05-27filter: pci and sdio ports under the platform driver filterAleksander Morgado1-1/+4
Do not automatically probe serial ports under the 'pci' or 'sdio' platform drivers unless explicitly tagged with ID_MM_PLATFORM_DRIVER_PROBE. $ realpath /sys/class/tty/ttyS0/ /sys/devices/pci0000:00/0000:00:16.3/tty/ttyS0 $ basename $(realpath /sys/devices/pci0000:00/0000:00:16.3/subsystem) pci
2018-05-24filter: add 'nozomi' and 'qcaux' drivers to MM_FILTER_RULE_TTY_DRIVERDan Williams1-0/+2
nozomi and qcaux only drive modems and thus should be included in this filter rule. Allows nozomi/qcaux devices to work automatically with strict filter mode.
2018-05-07filter: fix option1 driver nameAleksander Morgado1-1/+1
This was preventing TTY-only ZTE and Huawei modules from being grabbed in STRICT mode. https://bugs.freedesktop.org/show_bug.cgi?id=106253 https://bugs.freedesktop.org/show_bug.cgi?id=106234
2018-01-18filter: cdc-acm protocols 1 through 6 are all AT-capableAleksander Morgado1-2/+18
As per USB-IF "Class definitions for Communication Devices 1.2" docs. Reported-by: Iván Sánchez Ortega <ivan@sanchezortega.es>
2017-12-05filter: additional strict rules when all device ports availableAleksander Morgado1-3/+40
All the previous filter rules were applicable per-port independently. But, we also want to apply rules on a port based on the existence of other ports on the same device (e.g. allow TTY if the device also has a NET port). In this case, we need to wait for all ports to appear and then apply the additional rules. We re-use the "min wait time" timeout in the plugin-manager for this same purpose. This timeout is setup to wait for ports to appear before starting the probing process (e.g. so that plugin filters like the forbidden-drivers one work). The very same timeout can therefore be used to check whether we start the probing or not based on additional filter rules.
2017-12-05filter: new automatic whitelisting rules and strict/paranoid policiesAleksander Morgado1-7/+71
The 'default' filter policy was based on blacklisting as much as possible and otherwise allow. The new 'strict' filter policy will be based on whitelisting as much as much as possible, using custom defined rules, and otherwise forbid the ports. The new 'paranoid' filter policy is equivalent to the 'strict' filter after having applied the blacklist rules from the 'default' filter.
2017-12-05filter: explicitly allow port when ID_MM_PLATFORM_DRIVER_PROBE is setAleksander Morgado1-4/+7
Don't assume that the port will be implicitly allowed afterwards.
2017-12-05filter: let the user tag modems explicitlyAleksander Morgado1-0/+11
The user can tag modems (either full devices or ports independently) to be explicitly probed by ModemManager, using the new "ID_MM_DEVICE_PROCESS" udev tag, e.g.: $ sudo vim /lib/udev/rules.d/78-mm-whitelist-internal-modem.rules ACTION!="add|change|move", GOTO="mm_whitelist_internal_modem_end" ATTRS{idVendor}=="1199", ATTRS{idProduct}=="a001", ENV{ID_MM_DEVICE_PROCESS}="1" LABEL="mm_whitelist_internal_modem_end" $ sudo udevadm control --reload $ sudo udevadm trigger This rule runs before any other filter rule. This tag may be used e.g. by manufacturers building systems with built-in modems that will always be available. Distributions targeting support for multiple modem devices shouldn't use this udev tag.
2017-12-05filter: allow enabling/disabling rules via envvarsAleksander Morgado1-1/+38
E.g. forcing a MBIM modem to run in AT-only mode: # MM_FILTER_RULE_NET=0 \ MM_FILTER_RULE_CDC_WDM=0 \ /usr/sbin/ModemManager --debug This is just for quick testing for now.
2017-12-05filter: remove bogus TTY virtual console filterAleksander Morgado1-12/+3
The more generic filter for virtual devices already covers all cases covered by the TTY virtual console filter.
2017-12-05filter: new object to run the port/device filter logicAleksander Morgado1-0/+207
This new object allows configuring the filter rules applied to the device ports. By default, for now, it implements the same rules as the MMKernelDevice is_candidate() method, which is obsoleted.
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-21 18:24:27 +0000