In preparation for the multi-SIM setup, we need a way to tell whether
a given SIM card is active or not in the system.
On systems with one single SIM slot, the available SIM card will
always be active.
On Multi-SIM Single-Standby setups we may have multiple SIM slots with
multiple SIM cards, but only one of them will be active at any given
time.
On Multi-SIM Multi-Standby setups we may have multiple SIM slots with
multiple SIM cards that may be active at the same time. E.g. the QMI
protocol allows up to 5 different active SIM cards (primary,
secondary, tertiary...).
CHAP is almost universal nowadays, and so it is a better default
than PAP
Not changed for uBlox, that prefers an error if not specified,
and for Huawei, which uses NONE with user/pwd and has 2 CHAP choices
Instead of using the FALSE return of the method to indicate either a
fatal error (if result_error was set) or the continuation request (if
result_error wasn't set), provide a enum that has explicit states for
all three possible values (failure, success or continue).
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.
Aleksander Morgado
Giacinto Cifelli
Amol Lad
Ben Chan