It has the same exact format as MMBaseModemAtCommand, but its contents
are assumed heap allocated.
The only real purpose of this type is to allow defining static
constant MMBaseModemAtCommand variables without warnings when using
-Wdiscarded-qualifiers.
sierra/mm-broadband-bearer-sierra.c: In function ‘dial_3gpp_context_step’:
sierra/mm-broadband-bearer-sierra.c:304:18: error: this statement may fall through [-Werror=implicit-fallthrough=]
304 | ctx->step++;
| ~~~~~~~~~^~
sierra/mm-broadband-bearer-sierra.c:306:5: note: here
306 | case DIAL_3GPP_STEP_PS_ATTACH:
| ^~~~
sierra/mm-broadband-bearer-sierra.c:398:18: error: this statement may fall through [-Werror=implicit-fallthrough=]
398 | ctx->step++;
| ~~~~~~~~~^~
sierra/mm-broadband-modem-sierra.c: In function ‘modem_time_load_network_time’:
sierra/mm-broadband-modem-sierra.c:1733:5: error: enumeration value ‘TIME_METHOD_UNKNOWN’ not handled in switch [-Werror=switch-enum]
1733 | switch (MM_BROADBAND_MODEM_SIERRA (self)->priv->time_method) {
| ^~~~~~
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.
