The numeric fields in the +COPS=? response were relying on a very weak
parsing logic, assuming that they were single-digit numeric values and
not using the common string to integer conversion utilities.
This commit improves the conversion from the 3GPP/ETSI defined network
availability and access technology values to the MM defined ones,
providing enum-based matches even if the numeric values are the same.
The commit also fixes the parsing of access technology values > 10,
required to report 5G related values.
+CGDCONT? may list profiles with IDs that are illegal to write, i.e.
+CGDCONT=? returns a minimum ID larger than some of the existing
profiles. E.g. for Fibocom L610-EU, +CGDCONT=? returns
+CGDCONT: (1-7),"IP",,,(0-3),(0-4)
+CGDCONT: (1-7),"IPV6",,,(0-3),(0-4)
+CGDCONT: (1-7),"IPV4V6",,,(0-3),(0-4)
+CGDCONT: (1-7),"PPP",,,(0-3),(0-4)
+CGDCONT: (1-7),"Non-IP",,,(0-3),(0-4)
while the default EPS bearer is established at profile 0:
+CGDCONT: 0,"IP","xxx","xxx.xxx.xxx.xxx",0,0
[...]
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
meson generates the `mm-daemon-enums-types` source and header files.
These are used when building `ModemManager` executable and different
plugins. However, these enums are only stated as dependencies on the
`ModemManager` executable build.
This has been fixed by also adding the generated files targets as
dependencies in the required plugins.
The `broadmobi`, `dlink`, `telit` and `tplink` plugins include the
`mm-port-enums-types.h` header. However, they do not use any symbol
defined there.
The `huawei` plugin as includes the `mm-port-enums-types.h` header
but it does not include the build targets as dependencies.
These issues have been fixed by removing the unnecessary includes
from `broadmobi`, `dlink`, `telit` and `tplink` plugins and by
including the enums build target in the `huawei` target.
This type was a JSON description bug in libqmi, it should have never
been a struct by itself. This was changed in libqmi by the 1.31.3
snapshot, so let's use the new methods instead of the deprecated ones.
The MBIM command PIN LIST returns only status of pin locks and omits
puk-locked facilities. This caused the pop-up window for unlocking
PUK is not shown after reboot.
Currenty active PUK lock has to be obtained using additional call
for PIN command but only single facility is supported this way.
If the modem is disabled:
* Polling is completely halted.
* Thresholds are disabled.
* The user is allowed to call Setup() or SetupThresholds() to change
the settings, even if the actual polling or thresholds setup isn't
in effect.
When the modem is enabled:
* Polling will be started if there is a existing polling rate.
* Thresholds will be setup based on the existing threshold settings.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/504
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.
Aleksander Morgado
Sven Schwermer
Prakash Pabba
Iñigo Martínez
Michal Mazur
Dylan Van Assche
Nagi Marupaka
Florence Chan