Expose the generic device id method as a public API for plugins.
Plugins can call this method first and then add their own device ids on
top in case the generic ones aren't specific enough like in the case of
Quectel modems.
Do not build the mask of "all" modes based only on the supported radio
interfaces, also filter out those modes that would not be available
based on the current capabilities enabled.
In GSM/UMTS+CDMA/EVDO multimode devices, the 4G and 5G mode switching
operations are exclusively limited to the capability selection that
has LTE+5GNR exclusively.
We cannot allow switching to 4G-only, 5G-only or 4G+5G if the current
capabilities have GSM/UMTS or CDMA/EVDO.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/503
We use capability switching logic exclusively for configuring GSM/UMTS+CDMA/EVDO devices
(regardless of whether it has LTE/5GNR or not) to add or remove the GSM/UMTS and CDMA/EVDO
capabilities.
Based on the same logic, we will allow 4 combinations for GSM/UMTS+CDMA/EVDO+LTE+5GNR device:
"GSM/UMTS+CDMA/EVDO+LTE+5GNR", "GSM/UMTS+LTE+5GNR", "CDMA/EVDO+LTE+5GNR" and "LTE+5GNR"
Similarly, we will allow 4 combinations for GSM/UMTS+CDMA/EVDO+LTE device:
"GSM/UMTS+CDMA/EVDO+LTE", "GSM/UMTS+LTE", "CDMA/EVDO+LTE" and "LTE"
And, we will allow 3 combinations for GSM/UMTS+CDMA/EVDO device:
"GSM/UMTS+CDMA/EVDO", "GSM/UMTS" and "CDMA/EVDO"
Also, supported combination modes should be based on current capabilities and not entirely
upon supported radio interfaces.
1) If current capability has "gsm-umts" or "cdma-evdo" or both, do not
support 4G only, 5G only, or 4G+5G combination modes
2) If current capability neither has "gsm-umts" nor "cdma-evdo", only support
combination modes involving 4G and 5G.
Keep LTE or 5GNR always in current capabilities if supported by device.
Since capability switching logic is exclusively used for configuring
GSM/UMTS+CDMA/EVDO devices, decide if to have GSM/UMTS or CDMA/EVDO or both
or none when loading current capabilities.
On MBIM modems the type of PIN cannot be specified in MBIM_CID_PIN query
command and the modem responds only remaining attempts for the currently
active lock.
If PIN1 is unlocked and user tries to disable (or enable) it, MM won't
get an update of remaining attempts in response to PIN Query. This value
is returned only after the Set command and MM need to store it in
all (pin/puk)_set_(enter/enable/change)_ready functions.
Previous solution was to call the mm_iface_modem_update_unlock_retries
directly from these functions but it caused the notification to be send
too early and invalid number was displayed to user sometimes.
Instead of this MM will store numbers of remaining attempts and send
them in a single notification from modem_load_unlock_retries.
When using udev, we rely on the kernel to timely report port additions
in the same device.
When not using udev, e.g. when using hotplug scripts in openwrt, we
use mmcli --report-kernel-event operations to report the port
additions, which may end up requiring much more time to process,
especially during bootup as we would be reporting a lot of port
addition events one after the other.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/493
The finish() method with the GTask result propagation must be in the
same context as the GTask creation itself, not elsewhere.
Code is reordered so that the async methods can be read from bottom to
top, with the finish() method that includes the GTask result
propagation at the very top.
We must keep a valid QmiClient reference for as long as the operation
runs, so that we can use it in all the request send operations we do,
and also so that we can remove the indication id upon completing the
operation.
The timeout id and indication id, which are also part of a single
power operation are also included in the operation context, because
they don't have any other meaning out of it.
The operation context is stored as task data.
As in the case of the timeouts, we should not pass a full reference as
data to the signal handler as we don't know how many times we'll
receive the signal or if we'll ever receive it.
We already make sure that the signal handler is disconnected when the
operation ends, so we can be sure the self pointer is valid while the
signal handler is connected.
The timeout may not be called if we remove it earlier (e.g. if the
indication is received) and therefore we must not pass a full new
reference, otherwise it may get leaked.
There is no problem with the validity of the self pointer in timeout
callbacks because we're removing the timeout as part of the operation
teardown logic.
If Mode online is triggered just after Mode LPM and Mode LPM
processing is not complete in modem, modem will not process the next
request and the device will be stuck in an unwanted modem power
state. Thus, wait for a mode change indication from the modem before
declaring that a power on/off has been successful.
When we have just enabled, we want to give it some time before
starting the registration process, so that any pending registration
update that may have been scheduled during the enabling phase is
applied. We don't want to trigger a new automatic registration if
e.g. we're already registered.
The 'ENABLE + 1' step is 'WAIT_FOR_ENABLED' really, and that should be
only used when the current state is not a final one. If we're already
enabled, or registered, or connected, then jump to 'REGISTER' right
away.
During the enabling phase, the modem may receive a lot of asynchronous
updates reporting registration info changes, but we were fully
ignoring them because the modem was not yet enabled. The problem with
this is that as soon as we reach the enabled state, we may not receive
additional info, so we would be left in 'enabled' state until new
asynchronous updates are received or until we start a connection
attempt.
We can solve this by triggering an explicit update with the
registration information that we have cached as soon as we're enabled.
Only if transitioning into a "registered" state ("home", "roaming",
"partner") or if "denied"; otherwise, assume LAC/TAC/CID are all
unknown.
This change makes the logic also reload the location info on
registration updates reported asynchronously via notifications.
The profile management APIs implemented by Microsoft in the MBIM
extensions provide certain features that are not available via other
means (e.g. ip type, access type preference, roaming allowance...).
Unfortunately, these APIs require the current list of profiles
installed in the modem to be a bit special; e.g. with one profile max
for each context/APN type. If this does not happen, the operations
will fail, or they will update contexts that should not be updated.
So, we disable for now the MBIM extension profile management support;
the logic is there, but not used by default.
The modem may report the 'apn-type' field is the one to be used as
index; if that's the case, allow setting and deleting profiles based
on the given 'apn-type' field.
This change also makes the internal profile management operations use
one index field or another, based on what the protocol implements.
Microsoft defined a new extended version of the "provisioned contexts"
operation from the generic MBIM basic connect service. This extended
version adds several new settings that can be stored in the profile
(e.g. IP type, media type, roaming allowance...).
But this new version has a huge drawback; we cannot specify single
profiles via their unique id while we perform update/delete operations
in the modem. Instead, Microsoft explains that we should use the
context type to identify the target context; but this will ONLY work
if we have one context defined for each type. As soon as we have
multiple contexts of the same type, this operation may fail or
otherwise update multiple contexts at once.
Dylan Van Assche
Aleksander Morgado
Prakash Pabba
Michal Mazur
Nagi Marupaka
Florence Chan