The foxconn shared utils are only built when MBIM is enabled, and
therefore the dell and foxconn plugins should only expect those shared
utils to be present if MBIM is enabled. The foxconn plugin will be
fully disabled when MBIM is disabled.
The fibocom shared utils are only built when MBIM is enabled, and
therefore the fibocom plugin should not expect them built
unconditionally, they will only be present if MBIM is enabled
Instead of warning about various unimportant things failing that don't
affect functionality, just print the logs in debug level and go on.
E.g. this warning can be completely skipped:
<wrn> [modem0/sim0] couldn't load GID2: Couldn't read data from UIM: QMI protocol error (16): 'NotProvisioned'
Instead of warning about various unimportant things failing that don't
affect functionality, just print the logs in debug level and go on.
E.g. this warning can be completely skipped:
<wrn> [modem0] couldn't load list of own numbers: Couldn't get MSISDN: QMI protocol error (16): 'NotProvisioned'
There are certain cases where we perform a lot of data processing just
for logging purposes. Having methods that let us know whether a given
log level will be printed before doing all that data processing is useful.
We were attempting to read 15 bytes unconditionally, regardless of the
size of the EF_gid1 and EF_gid2 files.
This operation would succeed in some SIM cards even if the actual file
lengths are shorter:
AT+CRSM=176,28478,0,0,15
+CRSM: 144,0,"FFFF"
OK
But the operation would fail in some other SIM cards due to the length
mismatch:
AT+CRSM=176,28478,0,0,15
+CRSM: 103,0
OK
Using 0 as requested length instructs the modem to read the length
specified in the EF status information, which is also the same
approach we do in QMI and MBIM.
AT+CRSM=176,28478,0,0,0
+CRSM: 144,0,"FFFF"
OK
When reading SMS PDUs during initialization or upon a notification of
a new PDU arriving, we should ensure that the array of messages
returned is of type PDU, and also validate whether the array contains
valid PDUs before processing them, otherwise we could be dereferencing
invalid memory.
This is trying to fix crashes like the following:
0x000059502b7ebaa2(ModemManager -mm-broadband-modem-mbim.c:7816)add_sms_part
0x000059502b7f5cf5(ModemManager -mm-broadband-modem-mbim.c:7849)sms_read_query_ready
0x000079e48edb36d3(libgio-2.0.so.0 -gtask.c:1230)g_task_return_now
0x000079e48edb2732(libgio-2.0.so.0 -gtask.c:1300)g_task_return
0x000079e48ee64ce5(libmbim-glib.so.4 -mbim-device.c:240)transaction_task_complete_and_free
0x000079e48ee6665f(libmbim-glib.so.4 -mbim-device.c:1017)data_available
0x000079e48ec65463(libglib-2.0.so.0 -gmain.c:3417)g_main_context_dispatch
0x000079e48ec6576e(libglib-2.0.so.0 -gmain.c:4211)g_main_context_iterate
0x000079e48ec659e2(libglib-2.0.so.0 -gmain.c:4411)g_main_loop_run
0x000059502b7796b1(ModemManager -main.c:217)main
0x000079e48e9f77a7(libc.so.6 + 0x000227a7)__libc_start_main
0x000059502b7794b9(ModemManager + 0x0005f4b9)_start
0x00007ffef825c6a7
This is an extremely tricky race condition.
* During SIM object initialization, we try to load SIM type (first
item loaded).
* MMSimMbim SIM type loading step runs preload_subscriber_info(),
which:
** Sets self->priv->preload = TRUE; so that it is not run anymore.
** Sets the sync monitor to clear preloaded info if sync needed.
** Runs the subscriber ready status operation asynchronously.
** Just before the subscriber ready status operation returns, the
system goes to sleep.
** The resume logic kicks in, and we flag the modem with sync
needed, which clears the self->priv->preload flag.
* Then the subscriber ready status operation response arrives, and we
store the IMSI and the other things.
* When the next initialization step happens, given that
self->priv->preload is cleared, we run attempt to run
preload_subscriber_info() again, and this time it finds the info like
IMSI is already set, so asserts:
0x00007cbcd287523f (libglib-2.0.so.0 - gtestutils.c: 3253) g_assertion_message
0x00007cbcd28752a2 (libglib-2.0.so.0 - gtestutils.c: 3279) g_assertion_message_expr
0x00005cbdab0a2dc0 (ModemManager - mm-sim-mbim.c: 253) subscriber_ready_status_ready
0x00007cbcd29a173b (libgio-2.0.so.0 - gtask.c: 1230) g_task_return_now
0x00007cbcd29a0799 (libgio-2.0.so.0 - gtask.c: 1300) g_task_return
0x00007cbcd2a548e0 (libmbim-glib.so.4 - mbim-device.c: 264) transaction_task_complete_and_free
0x00007cbcd2a562fc (libmbim-glib.so.4 - mbim-device.c: 1047) data_available
0x00007cbcd28534a6 (libglib-2.0.so.0 - gmain.c: 3417) g_main_context_dispatch
0x00007cbcd28537b1 (libglib-2.0.so.0 - gmain.c: 4211) g_main_context_iterate
0x00007cbcd2853a25 (libglib-2.0.so.0 - gmain.c: 4411) g_main_loop_run
0x00005cbdab034d26 (ModemManager - main.c: 217) main
0x00007cbcd25e16c5 (libc.so.6 + 0x000286c5) __libc_init_first
0x00007cbcd25e1781 (libc.so.6 + 0x00028781) __libc_start_main
0x00005cbdab034a40 (ModemManager + 0x00061a40) _start
In order to solve this, upon a sync request the ongoing preload
operation will be cancelled.
The g_date_time_new_from_unix_utc() method in glib2 may fail if the
given timestamp is too far into the future. The value is supposed to
be seconds since unix time origin, but internally it will be converted
into usecs, so any value longer than G_MAXINT64 / USEC_PER_SECOND
isn't allowed.
This is currently used in the CLI, and we're anyway ignoring the error
returned in that case, but at least it won't crash if it ever happens.
Older MBIM modems don't support the low level UICC reading extension
defined by Microsoft. In those case, fallback to reading the GID
values using AT commands wherever possible.
The SAR enable operation may be selecting an explicit SAR level by
itself, so make sure the protocol implementation reports back to the
interface the default level that was used while enabling SAR.
No level change is reported in the interface if the SAR is being
disabled.
This was already forbidden in the MBIM implementation, and we should
also have it in the QMI implementation, so just make it a generic
check in the interface.
mm_iface_modem_3gpp_profile_manager_set_profile() was changed so that
the input profile object was not touched, and instead a copy of the
same would be used within the method.
Unfortunately, that change missed the update of the IP type
normalization step, which would end up modifying the original settings
instead of the newly created copy.
Fixes 7464940971
When processing QMI and MBIM messages to report domain registration
updates, we should do that altogether so that we don't report bogus
transitions to idle if the registration state switches from one domain
to another.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/629
The behavior of GRegex changed in 2.73.2 once it was ported from pcre1
to pcre2. In some cases it was made more strict, which is fine, in
other cases it exposed some change in how it behaves on certain
matches that is not extremely clear whether it's ok or not.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2729
See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/601
See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/621
Either way, one thing that was assumed was that initializing all
GRegex/GMatchInfo variables to NULL and making sure they're NULL
before they're initialized by glib (especially the GMatchInfo) was a
good and safer approach.
So, whenever possible, g_autoptr() is used to cleanup the allocated
GMatchInfo/GRegex variables, and otherwise, g_clear_pointer() is used
to ensure that no free/unref is attempted unless the given variable is
not NULL, and also so that the variable is reseted to NULL after being
disposed.
Aleksander Morgado