If "enable refresh" is set, QMI modem expects an acknowledgement upon receiving a PDC refresh indication,
otherwise the modem resets assuming clients are facing an issue in refreshing their cache.
Register for PDC refresh indication without setting "enable refresh" TLV.
We would still receive the refresh indication to notify that the list of profiles stored has changed and
would not have to acknowledge the modem.
During profile setup, the profile manager normally disconnects a profile
before re-using it. We do not want to do this for the initial EPS bearer
because that would trigger de-registration.
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
Also bump the timeout for the +CFUN operations as they may take up to
10s according to the AT command manual (e.g. MA510).
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
In situations where the configured APN for the initial EPS bearer
(cid=1) does not match the APN for the actual connection, ModemManager
sets up a context (cid!=1) with the proper APN when connecting. If the
APN for the initial EPS bearer was not valid, the SIM may fall back to a
default one. If that default matches the APN for the proper connection,
the initial EPS bearer is re-used for the actual connection. In that
scenario, +CGACT? will report deactivated for the actual connection
context (cid!=1). ModemManager subsequently reports the connection as
disconnected.
+GTRNDIS? will always reflect the correct state for the context ID we
used to set up the ECM connection. Hence, it makes sense to use this
command to assess the connection status.
This has been tested with the MA510-GL modem module.
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
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.
Currently, LM940 is expected to have not LTE band extended, however they
have been introduced since version 24.01.516.
This change adds a software revision compare function for Telit modem
limited to LM9x0 modems (LM940 and LM960 share the same revision format
string) to verify if the current LM940 software revision is equal or
newer than 24.01.516 and enable/disable LTE band extended accordingly.
Currently, mm-shared-telit:Private:alternate_3g_bands value provided via
ID_MM_TELIT_BND_ALTERNATE tag.
This commit maps the value of alternate_3g_bands to the modem model,
detected via software version string.
Currently, mm-shared-telit:Private:ext_4g_bands value is inferred from
the #BND? response, based on the convention that the #BND? response has
4 tokens only if the modem has LTE extended bands.
This commit maps the value of ext_4g_bands to the modem model, detected
via software version string, which is a more reliable source.
Currently functions dealing with #BND request
- mm_telit_parse_bnd_query_response
- mm_telit_parse_bnd_test_response
- mm_telit_build_bnd_request
have all a long list of arguments configuring how to deal with the BND
string.
This commit reworks this list of arguments into a single new structure
"MMTelitBNDParseConfig" with the following advantages
- shorter list of arguments for the above functions
- future changes to this arguments will be transparent for the functions
above that only pass the values
- one single point where the structure is created: a new function
mm_shared_telit_get_bnd_parse_config.
When the data connection is started with AT^SWWAN, the modem expects
the DHCP discover packet from the TE while the command is running,
i.e. while the modem has not replied yet. In order to achieve that,
the bearer is marked as connected as soon as the command is
issued. This makes the NetworkManager start the DHCP process.
If the modem replies with an error, the bearer will be marked
disconnected later on.
See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/50
for a similar functionality in the ublox driver.
Includes minor coding style fixes from Aleksander Morgado
<aleksandermj@chromium.org>.
Signed-off-by: Christian Taedcke <christian.taedcke@lemonbeat.com>
The previously used COPS command to set to LTE-only mode did not work
for an ELS81 modem.
Now ^SXRAT is used to switch modes instead of COPS, if SXRAT is
supported by the modem.
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.
