Devices like the Netgear AC313U require explicit context monitoring,
otherwise the device may end up disconnected internally and MM would
still think that the connection is ongoing.
When a new USB device is hotplugged, e.g. a USB<->RS232 converter that
exposes a single ttyUSB0, these udev events happen:
add /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb/usb-device)
add /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb/usb-interface)
add /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0 (usb-serial)
add /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0/tty/ttyUSB0 (tty)
bind /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0 (usb-serial)
bind /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb/usb-interface)
bind /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb/usb-device)
Our udev rules in MM only added tags in the 'add' events, and it looks
like the only ones 'persistent' after this sequence are those of the
last event happening on the specific path.
This meant that all TTY subsystem rules (e.g. ID_MM_CANDIDATE) would
be stored for later check (e.g. if ModemManager is started after these
rules have been applied), which was ok. "udevadm info -p ..." would
show these tags correctly always.
But this also meant that the 'bind' udev event happening for the USB
device didn't get any of our device-specific tags, and so we would be
missing them (e.g. ID_MM_DEVICE_MANUAL_SCAN_ONLY) if MM is started
after the last event has happened. "udevadm info -p ..." would
not show these tags.
Modify all our rules to also run at the 'bind' events.
See, for context:
https://github.com/systemd/systemd/issues/8221
The Netgear AC341U seems to delay reporting packet service status
indications or actually not even send them. This leaves us with modems
in connected state in ModemManager but actually disconnected. We can
detect this situation by actively polling ourselves the connection
status.
See e.g. this case where the indication is received 2.5 mins after the
first OutOfCall error detected when loading statistics.
Aug 30 22:52:50 ModemManager[574]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> connected)
Aug 30 22:52:50 ModemManager[574]: <info> Simple connect state (8/8): All done
Aug 30 22:52:50 ModemManager[574]: <warn> Reloading stats failed: Couldn't get packet statistics: QMI protocol error (15): 'OutOfCall'
Aug 30 22:53:20 ModemManager[574]: <warn> Reloading stats failed: Couldn't get packet statistics: QMI protocol error (15): 'OutOfCall'
Aug 30 22:53:50 ModemManager[574]: <warn> Reloading stats failed: Couldn't get packet statistics: QMI protocol error (15): 'OutOfCall'
Aug 30 22:54:20 ModemManager[574]: <warn> Reloading stats failed: Couldn't get packet statistics: QMI protocol error (15): 'OutOfCall'
Aug 30 22:56:21 ModemManager[574]: <info> bearer call end reason (2): 'generic-client-end'
Aug 30 22:56:21 ModemManager[574]: <info> bearer verbose call end reason (3,2000): [cm] client-end
Aug 30 22:56:21 ModemManager[574]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connected -> registered)
The return status of mm_base_modem_at_command_finish() already
specifies whether an error has happened or not, so skip creating the
GError if we don't care about the actual error details.
g_free and g_object_unref are in form of `void (*)(gpointer)`, which
matches the GDestroyNotify signature. An explicit GDestroyNotify cast on
g_free and g_object_unref is thus not needed.
A default implementation to monitor the ongoing connection is provided in the
generic MMBroadbandModem, based on AT+CGACT? to check whether the PDP context
of the connection (identified by the cached cid) is active or not.
This commit also disables the connection monitoring logic in those plugins that
have custom connection methods.
The mm_base_modem_grab_port() now receives a MMKernelDevice directly from the
plugin, which is then stored in the MMPort corresponding to the port.
This means that we have direct access to e.g. all properties set by udev rules
everywhere, and we don't need additional GUdevClient objects (e.g. like the one
used in the Huawei plugin to detect NDISDUP support during runtime).
For virtual ports (e.g. generated during unit tests), we have a new 'generic'
kernel device object which just provides the values from the kernel device
properties given during its creation.
All ports of the same modem reported by the kernel will all be associated with
a common 'uid' (unique id), which uniquely identifies the physical device. This
logic was already in place, what we do now is avoid calling it the 'sysfs
path' of the physical device, because we may not want to use that to identify
a device.
This logic now also enables the possibility of "naming" the modems in a unique
way by setting the "ID_MM_PHYSDEV_UID" property in the "usb_device" that owns
all the ports.
E.g. a custom device has 4 modems in 4 different USB ports. The device path of
each USB device will always be the same, so the naming rules could go like this:
$ vim /usr/lib/udev/rules.d/78-mm-naming.rules
ACTION!="add|change|move", GOTO="mm_naming_rules_end"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.1", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-1"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.2", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-2"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.3", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-3"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.4", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-4"
LABEL="mm_naming_rules_end"
Each of the modems found will have a unique UID retrieved from the previous list
of rules. Then, "mmcli" has also been updated to allow using the UID instead of
the modem DBus path or index, e.g.:
$ sudo mmcli -m USB-MODEM-1
/org/freedesktop/ModemManager1/Modem/0 (device id '988d83252c0598f670c2d69d5f41e077204a92fd')
-------------------------
Hardware | manufacturer: 'ZTE CORPORATION'
| model: 'MF637'
| revision: 'BD_W7P673A3F3V1.0.0B04'
| supported: 'gsm-umts'
| current: 'gsm-umts'
| equipment id: '356516027657837'
-------------------------
System | device: 'USB-MODEM-1'
| drivers: 'option'
| plugin: 'ZTE'
| primary port: 'ttyUSB5'
| ports: 'ttyUSB5 (at)'
...
$ sudo mmcli -m USB-MODEM-1 --enable
...
This patch makes declarations bind to definitions within the same module
to prevent the potential ambiguity if referenced directly.
AddressSanitizer think they violated one definition rule, although
those symbols are accessed by address through their modules and do
not depend on the order of the libararies loaded.
In short:
* The 'sierra-legacy' plugin will handle all the old AT based modems,
including the DirectIP ones. This plugin is filtered by driver ('sierra' or
'sierra_net') and forbidden-drivers ('qmi_wwan' and 'cdc_mbim'). This plugin
should also grab HP and AT&T branded models if they are handled by the
proper kernel driver.
* The 'sierra' plugin will only handle QMI or MBIM based Sierra modems, which
are really all the new ones. This plugin is filtered by VID (0x1199) and
driver (qmi_wwan and cdc_mbim).
For this separation to work, the 'sierra' and 'sierra_net' plugins need to be
complementary to each other.
Devices with Icera chipsets (USB305) don't support the Qualcomm
proprietary $QCPDPP command, and we must use the Icera command
instead. Otherwise authenticated bearer creation will fail.
MMBroadbandModemSierraIcera is not a subclass of
MMBroadbandModemSierra, so we cannot cast it to that type when
passing it to bearer creation. Luckily the bearer doesn't
care, so just downgrade the type to MMBroadbandModem.
Aleksander Morgado
Amol Lad
Ben Chan
Ting-Yuan Huang
Dan Williams