| Age | Commit message (Collapse) | Author |
|---|
|
src/mm-sim-mbim.c:1134:30: warning: unused variable 'request' [-Wunused-variable]
g_autoptr(MbimMessage) request = NULL;
^
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/684
|
|
|
|
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.
|
|
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.
|
|
|
|
This would be the application id that refers to the active SIM card.
|
|
|
|
Fixes 86f6d3351351f7143a7f1c5fb90ddb465089ac69
|
|
|
|
During initialization if the number of slots is more than 1 then
update the sim-type and esim-status of the inactive slot as well.
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/510
|
|
E.g. if we have an eSIM without profiles.
|
|
On MBIM modems the type of PIN cannot be specified in MBIM_CID_PIN query
command and the modem responds only remaining attempts for the currently
active lock.
If PIN1 is unlocked and user tries to disable (or enable) it, MM won't
get an update of remaining attempts in response to PIN Query. This value
is returned only after the Set command and MM need to store it in
all (pin/puk)_set_(enter/enable/change)_ready functions.
Previous solution was to call the mm_iface_modem_update_unlock_retries
directly from these functions but it caused the notification to be send
too early and invalid number was displayed to user sometimes.
Instead of this MM will store numbers of remaining attempts and send
them in a single notification from modem_load_unlock_retries.
|
|
This reverts commit 46c5cd8b7279e6139466664f87d744a0553fa1c3.
|
|
We can use the MBIMEx v3.0 support to load the SIM type, SIM
removability details and eSIM status.
|
|
Whenever MBIMEx v3.0 is enabled, the logic should parse the response
and indication messages using the updated format.
|
|
Instead of running the Susbcriber Ready Status separately for IMSI and
ICCID, we run it only once and store the results in a new private
struct.
It only saves one request/response right now, but it will save more
once introduced other SIM parameters loaded with the same method.
|
|
Don't close the UICC channel only when the EID was successfully
load. If for any reason it failed, also close the channel.
|
|
|
|
Support is added to set eid dbus interface property using
MBIM protocol when the inserted sim is esim.
|
|
|
|
QMI modems remove trailing F in 19 digit ICCID. Do the same on
MBIM modems for consistency.
|
|
|
|
Calling the mm_iface_modem_update_unlock_retries function directly from
pin_set_enter_ready caused a notification to be send too early with
invalid number of attempts to unlock on MBIM modems.
The mm_iface_modem_update_unlock_retries is already called for all
modems from send_pin_ready (mm-base-sim.c).
|
|
Increase the timeout from 10 seconds to 30 seconds when reading the
operator information through the MBIM_CID_HOME_PROVIDER query.
We have observed cases where it took more than 12 seconds on a Fibocom
L850-GL modem with specific China Unicom SIMs.
This timeout was actually the cause of a corruption of the operator name
(e.g. returning '@' rather than the real operator name) on the Intel
XMM7360 based L850-GL. The following scenario was happening:
- the base-sim code sends a first MBIM 'home-provider' query to read the
operator identifier.
- this query times-out after 10 seconds.
- the base-sim immediately sends another MBIM 'home-provider' query to
read the operator name.
- the modem returns a corrupted operator identifier.
Intel helped for the debugging and indicates that when the first query
happens, the modem starts reading the SIM files (EF SPN/PNN), apparently
it's taking a long time, when it's receives the second query while the
first one is not entirely processed, this triggers a bug (in the modem
firmware) and returns a corrupted name.
|
|
Move the logic out of the base modem, and make it applicable only for
MBIM modems.
|
|
In preparation for the multi-SIM setup, we need a way to tell whether
a given SIM card is active or not in the system.
On systems with one single SIM slot, the available SIM card will
always be active.
On Multi-SIM Single-Standby setups we may have multiple SIM slots with
multiple SIM cards, but only one of them will be active at any given
time.
On Multi-SIM Multi-Standby setups we may have multiple SIM slots with
multiple SIM cards that may be active at the same time. E.g. the QMI
protocol allows up to 5 different active SIM cards (primary,
secondary, tertiary...).
|
|
|
|
|
|
After MMSimMbim performs a MBIM_CID_PIN set operation, it calls
mm_iface_modem_update_lock_info() (through its base class MMBaseSim) to
refresh the unlock retries information, which results in a MBIM_CID_PIN
query. However, a MBIM_CID_PIN query reports only the information of one
PIN type and the PIN type can't be specified, we need to deduce the
number of retries left for a specific PIN type from the response of a
MBIM_CID_PIN set operation for that PIN type. To allow that, this patch
modifies MMSimMbim to update the unlock retries information after a PIN
operation based on the response to the MBIM_CID_PIN set operation.
|
|
|
|
g_free and g_object_unref are in form of `void (*)(gpointer)`, which
matches the GDestroyNotify signature. An explicit GDestroyNotify cast on
g_free and g_object_unref is thus not needed.
|
|
mbim_message_response_get_result() is available in libmbim-glib 1.11.1.
|
|
Just so that we don't have same header names in src/ and /libmm-glib.
|
|
|
|
This patch addresses a potential memory leak when load_sim_identifier or
load_imsi in MMSimMbim is called but the caller does not provide a
GAsyncReadyCallback.
|
|
This patch addresses a potential memory leak when
load_operator_identifier or load_operator_name in MMSimMbim is called
but the caller does not provide a GAsyncReadyCallback.
Reported by Aleksander Morgado <aleksander@lanedo.com>
|
|
|
|
|
|
Sync with libmbim commit:
commit b73673bf30a82e95819deb17296c9234399f0795
Author: Aleksander Morgado <aleksander@lanedo.com>
Date: Thu Apr 11 20:07:12 2013 +0200
mbim-codegen: properly define the 4 types of messages that we may have
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Already handled by the MbimDevice if none given.
|
|
|
|
|
