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'
We're bumping the current "INFO" level messages to the new "MSG"
level, also making the new level the default.
The old "INFO" level will be used to setup an intermediate level of
logging which is not as verbose as "DEBUG" but still provides some
capabilities to analyze the behavior of a modem.
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
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.
Aleksander Morgado
Aleksander Morgado
Aleksander Morgado
Michal Mazur
Teijo Kinnunen
Pavan Holla
Eric Caruso
Ben Chan