The synchronization after resume should only be needed on enabled
modems, as otherwise there is really no chance that the state of the
modem may have changed during suspend.
E.g. if a modem is failed because it doesn't have a SIM card, or if
the SIM-PIN is locked, or if the modem has never been enabled, there
is no point in attempting to synchronize the runtime state of the
modem.
The mm_base_modem_sync() method is an asynchronous method that
receives a callback and user data, and therefore we MUST always
complete the async method calling that callback. Set that up with a
GTask as usual.
Also, the mm_base_modem_sync_finish() method should be implemented
along with mm_base_modem_sync(), not in the source file of the
caller of the async method. The finish() always depends on how the
async method was implemented, in our case using a GTask.
Under certain rare conditions (e.g. race between querying devices of a
given subsystem and the kernel tearing those devices down), the
subsystem reported for a GUdevDevice seems to be NULL.
So, ensure both subsystem and name are set on the GUdevDevice before we
process them.
The issue has been observed on GUdevDevices listed by
g_udev_client_query_by_subsystem(), not on the ones asynchronously
reported via uevents, but we add the validity check on both places for
consistency.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/343
The logic that creates the device identifier uses some fields that are
exposed in DBus (e.g. model, manufacturer...).
We should not attempt to load any of that info if the DBus skeleton
for the Modem interface is no longer available, as e.g. the device may
have gone away already.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/374
When we receive an indication reporting a network-initiated
disconnection, convert the MBIM network error into a
MMMobileEquipmentError, and publish it in the new 'ConnectionError'
property.
When we receive an indication reporting a network-initiated
disconnection, convert the QMI call end reason into a
MMMobileEquipmentError, and publish it in the new 'ConnectionError'
property.
By default, fallback to "unknown" mobile equipment error when the
modem gets disconnected by the network and we don't have any way to
know a more detailed reason.
When a user-requested connection attempt fails, we not only return the
connection error to the user that requested it, we also publish the
specific connection error in DBus for others to check why the failure
happened.
This new property will provide detailed information about the failed
connection attempt, or about the network initiated disconnection. The
property will be cleared only if a new connection attempt is
triggered, and so it can be used to investigate why a given attempt
failed without needing to be the one who triggered the attempt (e.g.
so that failures in NetworkManager-triggered connection attempts can
be investigated looking at the DBus API).
The property is built as a (ss) tuple, but the libmm-glib interface
provides methods to read this property as a GError.
Since ModemManager 1.0 we were publishing symbols to identify all the
possible DBus error name prefixes, but these were never documented,
they were explicitly ignored in gtk-doc.
Let's provide proper documentation for them and make them first-class
API symbols.
On a failed QMI modem connection, we won't return the generic
"CallFailed" error, we'll try to convert the 3GPP verbose call end
reason to a MMMobileEquipmentError.
And if we cannot find a mapping, or if the reported error is not a
3GPP verbose call end reason, we'll return a Unknown
MMMobileEquipmentError with a string message providing detailed error
information.
Instead of having a switch with a lot of cases, provide a one to one
mapping for the MbimNwError and MMMobileEquipmentError codes in an
array, and make use of the mm_mobile_equipment_error_for_code() helper
to build the actual GError.
Update the list of mobile equipment error codes according to v17.1.0
of 3GPP TS 27.007 (March 2021).
A lot of the enum values that were prefixed with the 'GPRS_' keyword
have now been flagged as deprecated, and a new enum name given to the
corresponding value.
The deprecated symbol names are kept in the compat support to avoid
breaking API/ABI.
First, simplify the logic that attempts to find the correct error code
associated to an error text string. This logic is very flaky, as it
relies on knowing what the modems report as text string for the
different error codes, and obviously that is not always the same.
Instead of supporting all error codes in this logic, we now limit them
to a small subset with common error codes and hopefully common error
strings.
Second, in order to quickly get the error description string for a
given error code, we rework the array of supported errors so that
the index of the array is the error code itself. For mobile equipment
errors the logic is straightforward, as they're always in the [0,255]
range, but for the message errors we create an array where the index
of the array is equal to the code plus 300 as they're always in the
[300,500] range. By doing this, we avoid having an array with 300 NULL
items before the actual values we want to support.
Use the new generic FCC unlock step instead of implementing it within
the operating mode setup logic.
The operation is implemented in the MMSharedQmi interface as it will
also be used by the MBIM modem object.
There are devices that come locked before they can be put online.
Until now we had a specific implementation for this in the generic QMI
modem, but we should have it in a more generic way for any kind of
modem.
With the recently added support for modems using QRTR, ModemManager
needs to have access to the corresponding address family so it can
interact with the modem.
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
