when mm_iface_modem_refresh_signal() is called, we'll restart the
signal quality refresh logic already, there is no need to request
an enforced start.
The enforced start was also modifying ctx->enabled unconditionally,
which is really not ok. This logic would be enabled only when we're
registered, and that logic is fine, no need to change that.
We made sure that the after resume synchronization was only started on
modems that had been enabled (and so unlocked). If we detect a locked
SIM card during the sync operation, it's either because the SIM card
was swapped, or because the modem was fully shutdown during the
suspension (and so the SIM requires SIM-PIN again).
Either way, we cannot sync the state cleanly at this point, we must
trigger a full modem reprobe in order to move back the modem state to
Locked.
Refresh signal strength and access technologies,
check for SIM swaps, and check if the SIM is locked.
The modem may have switched to a different
access technologies or have a different signal strength
when resuming. Moreover, the user may swap or remove
the SIM when suspended.
When calling an async method ona given type, the convention is to use
the same type in the corresponding ready() method, so that we can use
it without additional casts on the finish().
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.
Aleksander Morgado
Dylan Van Assche
Michal Mazur