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
Commit d27e40ae9 ("core: new `Initializing' state in the global modem
state machine") added a 'wait_for_unlock_id' field to SendPinPukContext,
but never actually set it up.