| Age | Commit message (Collapse) | Author |
|---|
|
Otherwise we'll get a NULL pointer dereference segfault in mm_auth when
sending SIM PIN.
Looks like MMBaseSim was accidentally missed during the conversion done
by the commit in the Fixes tag below.
Fixes: ef5cee3ab578 ("auth-provider: move auth provider logic into each class")
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
|
|
Continues removing usage of MMBaseModem in a bunch of files
by splitting out bits of its usage to separate interfaces.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
|
|
Rather than make all of them rely on MMBaseModem for it. This
lets us disentangle dependencies for easier unit testing.
For interfaces, rather than casting directly to MMBaseModem
use intermediate interfaces (MMIfaceAuth and MMIfaceOpLock)
that tests can fake out.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
|
|
|
|
The logic initializing the SIM object already prints the loaded
fields, taking into account that some of them should be treated as
personal info (so redacted by default).
[modem0/sim0] loaded SIM identifier: 8988211000000123456
[modem0/sim0] loaded SIM identifier: ###
[modem0/sim0] loaded IMSI: 901700000012345
[modem0/sim0] loaded IMSI: ###
|
|
|
|
SIMCOM A760xE-H modems can answer to AT+CRSM=176,28589,0,0,4 request in 10s or more, so use rather big timeout (20s)
|
|
We want to ensure that all errors reported via DBus operations are
normalized to MM-specific errors.
We don't want to return QMI or MBIM specific errors, as those are
protocol specific and we don't want DBus clients to need to rely on
knowing which is the protocol in use by the device.
|
|
|
|
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 will print all the loaded SIM contents, treating as personal info
the SIM ICCID, IMSI and EID.
|
|
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
|
|
We were not even trying to load it if GID1 was successfully loaded.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
All properties loaded during initialization are meant to be loaded
only once, no point in saying that for each property.
|
|
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.
|
|
We implement the methods to load the properties during SIM object
initialization.
|
|
The ready() methods for each step in the initialization sequence must
be ordered from bottom to top, so that we can read the logic in that
same order.
|
|
|
|
|
|
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.
|
|
Implement Sim.SetPreferredNetworks method by using the AT+CPOL command.
|
|
This commit includes D-Bus processing and documentation, but not any
modem access implementation.
|
|
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.
|
|
Use the generic mm_modem_charset_bytearray_to_utf8() instead.
|
|
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.
|
|
It makes much more sense than returning a gchar array, as gchar is
signed.
|
|
Optionally given explicitly, and -1 can be used to assume it's
NUL-terminated.
|
|
This util method checks whether the input string is a valid hex
string, so make sure we return a GError on failure.
|
|
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).
|
|
This provides a new D-Bus property on the Sim object that
exposes the EID of the SIM, if available.
|
|
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.
|
|
If a SIM is inactive we cannot perform any SIM-PIN or SIM-PUK related
operation with it.
|
|
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...).
|
|
|
|
|
|
This avoids issues when e.g. sending SIM-PIN while the modem is
already unlocked or when SIM-PIN is not enabled.
Under those conditions, the needlessly sent SIM-PIN unlock attempt may
fail while libmm-glib/mmcli reports a successful operation. E.g.:
# mmcli --sim=/org/freedesktop/ModemManager1/SIM/0 --pin=3497
successfully sent PIN code to the SIM
But in reality...
Wed Nov 20 14:38:52 2019 daemon.debug [4254]: <debug> [1574260732.489513] Verifying PIN...
Wed Nov 20 14:38:52 2019 daemon.debug [4254]: [/dev/cdc-wdm0] sent message...
<<<<<< RAW:
<<<<<< length = 27
<<<<<< data = 01:1A:00:00:0B:02:00:09:00:26:00:0E:00:02:06:00:01:04:33:34:39:37:01:02:00:06:00
Wed Nov 20 14:38:52 2019 daemon.debug [4254]: [/dev/cdc-wdm0] sent generic request (translated)...
<<<<<< QMUX:
<<<<<< length = 26
<<<<<< flags = 0x00
<<<<<< service = "uim"
<<<<<< client = 2
<<<<<< QMI:
<<<<<< flags = "none"
<<<<<< transaction = 9
<<<<<< tlv_length = 14
<<<<<< message = "Verify PIN" (0x0026)
<<<<<< TLV:
<<<<<< type = "Info" (0x02)
<<<<<< length = 6
<<<<<< value = 01:04:33:34:39:37
<<<<<< translated = [ pin_id = 'pin1' pin_value = '3497' ]
Wed Nov 20 14:38:52 2019 daemon.debug [4254]: [/dev/cdc-wdm0] received message...
<<<<<< RAW:
<<<<<< length = 30
<<<<<< data = 01:1D:00:80:0B:02:02:09:00:26:00:11:00:02:04:00:01:00:52:00:13:02:00:69:84:10:02:00:03:0A
Wed Nov 20 14:38:52 2019 daemon.debug [4254]: [/dev/cdc-wdm0] received generic response (translated)...
<<<<<< QMUX:
<<<<<< length = 29
<<<<<< flags = 0x80
<<<<<< service = "uim"
<<<<<< client = 2
<<<<<< QMI:
<<<<<< flags = "response"
<<<<<< transaction = 9
<<<<<< tlv_length = 17
<<<<<< message = "Verify PIN" (0x0026)
<<<<<< TLV:
<<<<<< type = "Result" (0x02)
<<<<<< length = 4
<<<<<< value = 01:00:52:00
<<<<<< translated = FAILURE: AccessDenied
As we already know what the current lock status is, just abort the
user operation if the unlock operation isn't required.
|
|
|
