This new method allows querying the modem for information about the
current serving cell(s) as well as any other neighboring cell that may
be found.
The information for the cells is given in an array of dictionaries,
where each element of the dictionary is a new dictionary itself.
Each cell type has a different set of properties that may be given in
the dictionary, and some of those properties in each type are also
applicable under certain conditions (e.g. only applicable to the cell
if it's a 'serving' cell instead of 'neighboring').
The API documentation explains in detail what is expected in each
case.
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.
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.
In order to show the properties of the profile management interface, e.g.:
$ sudo mmcli -m a --3gpp-profile-manager-status
-----------------------------------
3GPP profile manager | index field: apn-type
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.
For most protocols, the operations to manage profiles require a unique
'profile-id' as index. This applies to AT, QMI and generic MBIM.
But for MBIM using the Microsoft Extensions for profile management,
this is no longer true; the device expects the 'apn-type' to be the
index.
This new property lets the user know which is the expected index field
in the Delete() and Set() operations.
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.
The 'allow-roaming' setting should be considered deprecated for 3GPP
devices that support the new 'roaming-allowance' setting, which is
much more detailed (as it allows to differentiate between partner and
non-partner networks) and may also be stored as part of a profile.
This setting is stored as part of the profile in the device, and
allows the user to specify that a given profile must not be used in
any way by the modem (if set to 'FALSE').
In 5G capable devices, which can support multiple types of access
types (either 3GPP or non-3GPP), the UE may request to use a 3GPP
access type exclusively, prefer a 3GPP access type, or just report no
preference.
When supported, this field may also be part of the settings that can
be stored as part of a profile.
By the time we report the bearer as 'Connected', the DBus client
should also be able to know right away the value of
'ReloadStatsSupported', instead of needing to wait for it to be
updated asynchronously.
This logic adds one additional step in the generic connection
sequence for this purpose, which is run after the modem is connected
but before we report the state change via DBus.
We originally did only 3 attempts every 3s, so the maximum probing
time for a given TTY port looking for AT capabilities was 9 seconds.
We now duplicate the amount of times, so up to 18s of port probing,
which is quite a lot more than before, but unfortunately it's needed
because most new modems take a lot of time to boot up internally.
The way to avoid this long probing time is to make sure port type
hints for the possible AT ports are set correctly.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/379
The ModemManager codebase has been ported to support Basic Connect v3
messages as defined in MBIMEx v3.0, so at this point we can now switch
to use it by default whenever possible.
Whenever MBIMEx v3.0 is enabled, the logic should create requests and
parse responses using the updated format.
Based on an initial implementation by Som_SP <somashekhar.puttagangaiah@intel.com>
Whenever MBIMEx v3.0 is enabled, the logic should create requests and
parse responses using the updated format.
Based on an initial implementation by Som_SP <somashekhar.puttagangaiah@intel.com>
When an eSIM doesn't have any profile set, we should treat it as fully
ready to be used; i.e. so that a new SIM object can be created and
initialized.
In this state, the "eSIM status" property will say "No profiles".
Instead of running the Susbcriber Ready Status separately for IMSI and
ICCID, we run it only once and store the results in a new private
struct.
It only saves one request/response right now, but it will save more
once introduced other SIM parameters loaded with the same method.
The udev rules expect matches based on shell globbing pattern, not
based on regex. This means that "[0-9]*" doesn't mean "zero or more
digits", it actually means "one digit and zero or more other
characters".
So, avoid the regex like match, even if it worked for us, because it
didn't mean what we thought it meant, plus, it breaks our custom udev
rules processing logic, in which we convert the input patterns into
real regex expressions.
See https://bbs.archlinux.org/viewtopic.php?pid=1415916#p1415916
While at it, also make sure that the wildcard matching is done
exclusively for prefix and suffix matches, never in the middle of
a string, or our custom rules parser would not match correctly.
If the modem reports any error during the connection status check,
we're creating a GError but never disposing it. We don't need that
GError for anything, so just discard it.
Added scripts for Foxconn SDX55, Quectel EM120, and several old Sierra
Wireless manufactured devices:
* Installed but not used by default, the user needs to setup manual
links from ${pkgdatadir}/fcc-unlock.available.d, to
${pkgsysconfdir}/fcc-unlock.d in order to enable them.
* Installed with rights only for the owner, so that the dispatcher in
ModemManager can validate them.
* They rely on $PATH to find the qmicli/mbimcli tools.
In addition to these scripts, per-vid:pid links are created in the
same ${pkgdatadir}/fcc-unlock.available.d directory, specifying which
are the specific devices that require the FCC unlock operation.
This patch also creates the ${pkgsysconfdir}/fcc-unlock.d and
${pkglibdir}/fcc-unlock.d directories where ModemManager looks for the
enabled tools.
Note that the meson setup doesn't support creating/deleting links
officially yet, so we use a workaround using meson.add_install_script
that is not perfect (i.e. doesn't handle the symlink removal during
uninstall). See https://github.com/mesonbuild/meson/issues/1602
We remove the built-in FCC unlock procedures from the ModemManager, we
will no longer run them automatically, and instead rely on external
scripts/programs to do that.
Packages providing the external FCC unlock tools can install them in
${pkglibdir}/fcc-unlock.d.
Users manually enabling external FCC unlock tools can install them in
${pkgsysconfdir}/fcc-unlock.d.
The user-enabled path takes precedence over the package-enabled one.
The input pattern given to the string_match() method is not a regex
pattern and we cannot use it as that, because all the special
characters (e.g. '.') would not be treated correctly.
Also, the prefix matching with the wildcard at the end of the string
needs to be converted to a proper regex wildcard, i.e. '.*'.
This logic also adds support for suffix matching, with a wildcard at
the beginning of the string, e.g. as the ones used for the wwan kernel
device name matching rules (i.e. '*MBIM').
Unit tests are added to cover all cases, most of these tests were
failing without the fixes implemented here.
We keep the 'WHITELIST-ONLY' filter type name still as an option in
--filter-policy=[POLICY], but deprecated and with the better
'ALLOWLIST-ONLY' replacement suggested from now on.
Aleksander Morgado