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.
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.
Before invoking AT+CPOL? for loading preferred networks list from
SIM, AT+CPOL=,2 is executed to make sure that the returned
operator codes are in expected (numeric) format.
Before reading preferred network list with AT+CPOL?, AT+CPLS=0 is
now invoked first to make sure that the correct PLMN list (i.e.
user-defined) is selected.
The ModemManager1.Sim.PreferredNetworks property contains the preferred
networks (and access technologies, if available) configured to the
SIM card.
This commit implements preferred networks reading with AT+CPOL.
Until now, this method would automatically apply transliteration;
i.e. replacing characters with '?' when no direct translation was
available.
We can attempt to do that transliteration on strings that are not
critical, e.g. the operator name reported by the network. But we
should not do that on other types of strings, e.g. on SMS contents
that may really have additional purposes than just being
human-readable.
This commit makes the transliteration option to be explicitly
requested by the caller.
Enabling/Disabling/Changing/Sending the PIN1 lock is usually limited to
3 retries. If these attempts are exhausted, the modem is puk_locked.
We reprobe the modem to get rid of any unwanted interfaces and move
to a locked state.
If the lock status cannot be read during a puk unblock attempt, reprobe
the modem. It is likely that the SIM was permanently blocked if the lock
status cannot be read.
SIMs can be created with an EID fetched during load_sim_slots
while initializing the modem, if present.
Since load_eid would be implemented with the same mechanism
we avoid using it here (if Get Slot Status fails once, it
probably doesn't make a lot of sense to try it again).
Before attempting to load any SIM property value, allow checking
whether the SIM is ready for operation or not.
This action is implicitly done by the "unlock required check" step
that is triggered before initializing the primary SIM card, but it
would not be done when initializing other available SIM cards.
The default SIM creation method will attempt to initialize the SIM
properties during the object creation.
This new method allows creating SIM objects with already known
property values, and therefore not explicitly running the
asynchronous initialization process.
This new property helps us identify in which SIM slot the SIM card is
inserted, when multiple slots are available, in the [1,N] range.
For the single-SIM systems this value will always be '0'.
This property is not publicly exposed in DBus, it is considered an
implementation detail.
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...).
mm-base-sim.c:1590:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
1590 | ctx->step++;
| ~~~~~~~~~^~
mm-base-sim.c:1592:5: note: here
1592 | case INITIALIZATION_STEP_SIM_IDENTIFIER:
| ^~~~
mm-base-sim.c:1606:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
1606 | ctx->step++;
| ~~~~~~~~~^~
mm-base-sim.c:1608:5: note: here
1608 | case INITIALIZATION_STEP_IMSI:
| ^~~~
mm-base-sim.c:1622:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
1622 | ctx->step++;
| ~~~~~~~~~^~
mm-base-sim.c:1624:5: note: here
1624 | case INITIALIZATION_STEP_OPERATOR_ID:
| ^~~~
mm-base-sim.c:1638:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
1638 | ctx->step++;
| ~~~~~~~~~^~
mm-base-sim.c:1640:5: note: here
1640 | case INITIALIZATION_STEP_OPERATOR_NAME:
| ^~~~
mm-base-sim.c:1654:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
1654 | ctx->step++;
| ~~~~~~~~~^~
mm-base-sim.c:1656:5: note: here
1656 | case INITIALIZATION_STEP_EMERGENCY_NUMBERS:
| ^~~~
mm-base-sim.c:1670:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
1670 | ctx->step++;
| ~~~~~~~~~^~
mm-base-sim.c:1672:5: note: here
1672 | case INITIALIZATION_STEP_LAST:
| ^~~~
Instead of reusing the caller GTask, use a new GTask to wrap the
execution of the subclass' async method implementation.
Also, rename the _ready() methods implemented in the GObject
initialization flow so that we can use the load_sim_identifier_ready()
function name.
When transitioning between power-low and power-on modes, Telit modems
switch the SIM off/on, which leads to the emission of #QSS unsolicited not
related to actual SIM swaps.
To handle this #QSS unsolicited, this patch:
* disables reacting on #QSS unsolicited when modem_power_down is received
* implements modem_after_power_up that:
- checks whether the SIM has been changed, matching cached SIM
Identifier with the value in the current SIM. If SIM Identifier,
is different, sim hot swap ports detected is called.
- re-enables reacting on #QSS unsolicited
Aleksander Morgado
Aleksander Morgado
Michal Mazur
Teijo Kinnunen
Pavan Holla
Eric Caruso
Ben Chan
Carlo Lobrano