We're bumping the current "INFO" level messages to the new "MSG"
level, also making the new level the default.
The old "INFO" level will be used to setup an intermediate level of
logging which is not as verbose as "DEBUG" but still provides some
capabilities to analyze the behavior of a modem.
The SIM slots ptr array should have a proper GDestroyNotify, so that
whenever the array is unref-ed as part of the modem disposal logic,
the SIM objects (and the modem object references they keep) are also
unref-ed.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/571
A failure loading IMSI or ICCID (unless for the UNSUPPORTED case)
could be an indication that there is no SIM.
Ideally, the logic checking if a SIM swap happened should have checked
first if there is a SIM card in the slot, and only if there is one go
on to try to load IMSI or ICCID.
The part generation logic is independent to whether the SMS send or
store operation failed, so just avoid doing the parts cleanup. E.g.
if we created the parts for store() but storing failed, the same parts
could still be used for send() successfully.
The internal list of parts in the base SMS object is created either
when the message is sent or when the message is stored.
The daemon should not expect the list of SMS parts to be empty upon a
store() operation requested via DBus, as the list of parts may have
already been created during send().
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/598
If any of the control ports ends up timing out 10 consecutive times,
the modem will be flagged as invalid and it will be reprobed from
scratch.
This allows us to detect modems that end up irresponsive in QMI or
MBIM while they're still exposed in e.g. the USB bus.
We don't have a clear way to report "unknown" signal quality, so for
now just skip printing it altogether in the mmcli human output if the
modem is not yet enabled.
Avoid calling the MMBaseSim class method directly, and use the helper
mm_base_sim_load_sim_identifier() instead.
Also, rework a bit the logic to have a single completion method once
we know the current ICCID.
If the reported eSIM doesn't have profiles, there is no point in
trying to load properties like ICCID, IMSI or operator name/id.
If the reported SIM is a physical SIM, there is no point in trying
to load properties like EID or eSIM status.
If we created the SIM objects during the SIM slots processing, we
should not attempt to reload the settings that were already set during
the re-initialization, as that may end up clearing the initial
properties.
E.g. if the error reported by the MbimDevice is a timeout error, it
means the connection attempt is still ongoing in the device, we need
to ask it to stop.
Commit b497de325 introduced a change by which some common errors (e.g.
SIM missing) would be reported as MM_CORE_ERROR_ABORTED.
This had the undesired effect of making the MMBaseModem object not
flag as valid the modem, because the returned error wasn't
MM_CORE_ERROR_WRONG_STATE.
We now change this logic so that only ABORTED makes the modem object
not flagged as valid, and we'll do that only if the Modem interface
isn't exposed in DBus.
Fixes b497de325
When we explicitly request to perform a SIM slot switch operation, we
should ignore the 'slot info status' and 'subscriber ready status'
indications that report an active SIM slot change, or otherwise they'll
end up interfering with the correct reporting of the slot switch
operation.
We could have attempted to complete the slot switch operation early
using the indications, but that solution would have forced us to
assume that theinfo in the indications is the one we had requested,
which is not easy because the 'slot info status' indication is
reported once for each slot, so a single SIM slot switch operation
triggers multiple 'slot info status' indications, as well as
additional 'subscriber ready status' indications reporting the same.
Fixes suggested by Pavan Holla <pholla@chromium.org> and tested by
Jinjian Song <Jinjian.Song@fibocom.com>.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/550
We no longer have separate mm_base_modem_process_sim_event() and
mm_broadband_modem_sim_hot_swap_detected() methods. The only
difference between both of them was that one of them would attempt to
cleanup the ports context associated to the SIM hot swap event logic
as soon as a swap was detected, in order to avoid queueing up multiple
such events.
The previous logic wasn't working well, though, as there could be
mixed AT+QMI or AT+MBIM devices that would also require that same
cleanup and so we didn't always know which one should have been
called.
Now we have a single mm_iface_modem_process_sim_event() method, which
will trigger the reprobe and disabling, but which will also perform
the cleanup of the SIM ports swap setup as specified by the
implementation.
So, if a plugin explicitly initializes the serial ports context for
SIM hot swap handling, it should also explicitly clean it up.
Also, the initialization of the serial ports context for SIM hot swap
handling is no longer done automatically for all modems, it will be
done only for those modems using it; i.e. the modems that explicitly
report support SIM hot swap handling using AT URCs.
This property is used in the MMIfaceModem to flag whether the SIM hot
swap setup has been performed or not. The flag is now moved to the
iface-specific private context.
The property was also used in AT-based modems, so that implementations
supporting the SIM hot swap via AT URCs could flag the upper layers
whether the enabling of the feature was done correctly or not, and if
so, create and keep the AT ports context open. But this feature only
made sense in AT-based modems, i.e. an MBIM modem that detects SIM hot
swaps via MBIM indications exclusively should not require the AT ports
context open for anything. The check in the MMBroadbandModem object
has therefore been removed, and the logic will be updated so that it
only applies to AT-based modems.
The signal and access tech loading operation was using a context that
contained both overall state and state specific to the current
attempt.
The overall modem state is now moved to the iface-specific private
context, and the state specific to the operation is kept in a GTask
that is bound to the ongoing loading operation.
Avoid keeping separate per-operation contexts, it doesn't make
sense. Just have one single Private context for the whole interface
where we can add support for all operations performed by the
interface.
The SIM hot swap operation relies on multiple different types of
indications, but the most important one is the subscriber info
indication. We should make sure that indication is kept enabled for as
long as the SIM hot swap detection should be active.
We also skip using the MM_IFACE_MODEM_SIM_HOT_SWAP_CONFIGURED
property, which should be removed or made MMBroadbandModem-specific,
as it is only really used in the AT-based SIM hot swap detection
logic.
This is not extremely important, because we don't really flag as
disabled those indications that failed to be enabled (as usually we
attempt to enable them in a group, not one by one), but in this case
this will allow us to keep a clean state after a failed SIM hot swap
setup.
It is important to gracefully stop the session before starting the
next session, making sure the engine is completely stopped. This can
be ensured by waiting for the +XLSRSTOP URC just after having received
the +XLSRSTOP command response.
We'll do an explicit wait for that URC with a 10s timeout, in order to
avoid waiting forever if the URC is never received. It will be assumed
that the engine is off if the 10s timeout happens, in the same way as
we were doing until now.
During the wait time for the URC, the operation task ownership is
shared among the response processor, the URC handler and the timeout
source. Once any of them decides to complete the task, the others will
automatically avoid attempting to complete the same task.
Based on a patch originally developed by:
Som_SP <somashekhar.puttagangaiah@intel.com>
==11025== 40 bytes in 1 blocks are definitely lost in loss record 3,313 of 5,483
==11025== at 0x483E7C5: malloc (vg_replace_malloc.c:380)
==11025== by 0x4A32CA9: g_malloc (in /usr/lib/libglib-2.0.so.0.7000.2)
==11025== by 0x4A4A082: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.7000.2)
==11025== by 0x49F8574: g_array_sized_new (in /usr/lib/libglib-2.0.so.0.7000.2)
==11025== by 0x24DEB1: load_supported_modes_mbim (mm-broadband-modem-mbim.c:958)
==11025== by 0x24E2D5: modem_load_supported_modes (mm-broadband-modem-mbim.c:1042)
==11025== by 0x1D4DC5: interface_initialization_step (mm-iface-modem.c:5718)
==11025== by 0x1D26D6: load_device_identifier_ready (mm-iface-modem.c:4903)
==11025== by 0x4BACB83: ??? (in /usr/lib/libgio-2.0.so.0.7000.2)
==11025== by 0x4BACBB8: ??? (in /usr/lib/libgio-2.0.so.0.7000.2)
==11025== by 0x4A2A434: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.7000.2)
==11025== by 0x4A7E7B8: ??? (in /usr/lib/libglib-2.0.so.0.7000.2)
We're returning the GError as GTask result, we should not explicitly
free it ourselves.
Fixes the crash sometimes seen in
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/550
==15994== Invalid free() / delete / delete[] / realloc()
==15994== at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==15994== by 0x4F9A8A0: g_error_free (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== by 0x2251CC: ??? (in /usr/sbin/ModemManager)
==15994== by 0x4DD2B48: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.7102.0)
==15994== by 0x4DD2D4A: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.7102.0)
==15994== by 0x4CA9049: ??? (in /usr/lib/x86_64-linux-gnu/libmbim-glib.so.4.6.0)
==15994== by 0x4CB0367: ??? (in /usr/lib/x86_64-linux-gnu/libmbim-glib.so.4.6.0)
==15994== by 0x4FAF287: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== by 0x4FAEC03: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== by 0x5003497: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== by 0x4FAE282: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== by 0x16916F: main (in /usr/sbin/ModemManager)
==15994== Address 0x80db490 is 0 bytes inside a block of size 16 free'd
==15994== at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==15994== by 0x4F9A8A0: g_error_free (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== by 0x1984FA: ??? (in /usr/sbin/ModemManager)
==15994== by 0x4DD2B48: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.7102.0)
==15994== by 0x4DD2D4A: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.7102.0)
==15994== by 0x2251A6: ??? (in /usr/sbin/ModemManager)
==15994== by 0x4DD2B48: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.7102.0)
==15994== by 0x4DD2D4A: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.7102.0)
==15994== by 0x4CA9049: ??? (in /usr/lib/x86_64-linux-gnu/libmbim-glib.so.4.6.0)
==15994== by 0x4CB0367: ??? (in /usr/lib/x86_64-linux-gnu/libmbim-glib.so.4.6.0)
==15994== by 0x4FAF287: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== by 0x4FAEC03: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== Block was alloc'd at
==15994== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==15994== by 0x4FB76F8: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== by 0x4FCF1A4: g_slice_alloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== by 0x4FCF80D: g_slice_alloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== by 0x4F9A3A6: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== by 0x4F9A5A3: g_error_copy (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== by 0x4CA903E: ??? (in /usr/lib/x86_64-linux-gnu/libmbim-glib.so.4.6.0)
==15994== by 0x4CB0367: ??? (in /usr/lib/x86_64-linux-gnu/libmbim-glib.so.4.6.0)
==15994== by 0x4FAF287: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== by 0x4FAEC03: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== by 0x5003497: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
==15994== by 0x4FAE282: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7102.0)
We cannot call peek_device() when we have already created a GTask for
the async operation, because if the operation failed we would be
completing the async operation with a totally different GTask than the
one we had created ourselves, triggering memory leaks and leaving
modem references around that should not exist (as the GTask we create
holds a modem reference).
Issue found in the context of debugging this, may actually be fully
related:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/550
The user or the packages can install custom dispatcher scripts that
will be run by the ModemManaer daemon itself upon bearer connection
status updates.
Scripts installed by users should go into the
/etc/ModemManager/connection.d directory.
Scripts installed by packages should go into the
/usr/lib/ModemManager/connection.d directory.
The name of the script will specify the order how it's run, so it's
suggested to name them with a numeric prefix, e.g. "99-something".
The BUFFER_FULL signal handler is effectively working in the same way
as the response buffer processor, in both cases we may have scheduled
the completion of the serial command, and that in turn may end up
fully disposing the port object. We must make sure the port object is
valid for as long as we need it in this function, so we take a
reference while processing the response buffer.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/535
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.
The set_initial_eps_bearer_settings() operation is the same in XMM
capable and generic MBIM modem objects. Place it in a common shared
interface so that we don't duplicate code.
Use the same logic always to decide which is the best GPS control/data
port, and then perform the initial port setup (GNSS engine off) only
that single port.
We're not going to implement all XMM shared operations from the shared
utils, as the newer Intel modems support the new operations in the
Microsoft MBIM Extensions.
Just inherit the GNSS management capabilities.
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.
We won't create a full new different modem object based on whether the
ID_MM_FIBOCOM_INITIAL_EPS_OFF_ON tag is found or not. Instead, we
always will create the same object type, and detect whether the OFF/ON
cycle is required during runtime.
Assume that the method to change the initial EPS bearer settings is
always implemented in the parent, so that we can avoid the runtime
check.
This also fixes the codepath that would happen if the
iface_modem_3gpp_parent->set_initial_eps_bearer_settings == NULL
condition was valid, as that would end up with a GTask never completed.
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
So that when the meson build does the template replacement, the
generated file is also executable and can be used as Exec line in the
test DBus service file.
Fixes the 'test-stub' unit test in meson.
The test service file is used in the test-plugin-generic unit tests,
which require the ModemManager daemon to be launched in a private test
DBus session.
Aleksander Morgado