| Age | Commit message (Collapse) | Author |
|---|
|
If the QMI modem is initialized without a SIM card in it, and it goes
to failed state, allow the modem to be reprobed when a SIM card is
inserted.
|
|
So that the list of ports shown in the Ports DBus property is also
alphabetically sorted by port name, instead of having a mess like
this:
-----------------------------
System | device: qcom-soc
| drivers: bam-dmux
| plugin: qcom-soc
| primary port: rpmsg0
| ports: rmnet5 (net), rmnet_usb0 (unknown), rmnet4 (net),
| rpmsg1 (at), rmnet3 (net), rpmsg0 (qmi), rmnet2 (net), rmnet1 (net),
| rmnet7 (net), rmnet0 (net), rmnet6 (net)
|
|
At the moment, ignored ports show up as (unknown) in the ports list
in mmcli. This makes it look like something went wrong while probing.
Actually ModemManager already tracks unknown and ignored ports separately
(MM_PORT_TYPE_UNKNOWN vs MM_PORT_TYPE_IGNORED) but the API always exposes
them as MM_MODEM_PORT_TYPE_UNKNOWN.
Add MM_MODEM_PORT_TYPE_IGNORED and use this for ignored ports so they
show up as (ignored) instead in mmcli.
|
|
No need to retry checking card status when the application state is
illegal, just treat the SIM card as unusable right away.
https://forum.sierrawireless.com/t/uim-card-application-state-illegal/21842
|
|
When "UIM Switch Slot" returns a NoEffect error it's because we're
already in the desired slot, so just treat it as a successful
operation.
|
|
Running with G_DEBUG=fatal-warnings will end up reporting warning logs
with G_LOG_FLAG_FATAL, which breaks our own logging logic.
|
|
|
|
If the modem goes away (ports removed) during the initialization
phase (e.g. while QMI clients are being allocated), the MMPortQmi
object will be closed and it will lose its internal QmiDevice.
We should therefore consider the lack of QmiDevice a valid usecase in
track_qmi_device_removed() and return a GError when that happens.
#0 0x00007fb544618cc9 in raise () from /lib/libc.so.6
#1 0x00007fb54461bd68 in abort () from /lib/libc.so.6
#2 0x00007fb544e2213d in g_assertion_message () from /usr/lib/libglib-2.0.so.0
#3 0x00007fb544e221ba in g_assertion_message_expr () from /usr/lib/libglib-2.0.so.0
#4 0x00000000004be584 in track_qmi_device_removed ()
#5 0x00000000004be5e3 in allocate_next_client ()
#6 0x00000000004be7b1 in qmi_port_allocate_client_ready ()
#7 0x00007fb5453690a3 in g_task_return_now () from /usr/lib/libgio-2.0.so.0
#8 0x00007fb54536967e in g_task_return () from /usr/lib/libgio-2.0.so.0
#9 0x00000000004dd8f8 in allocate_client_ready ()
#10 0x00007fb5453690a3 in g_task_return_now () from /usr/lib/libgio-2.0.so.0
#11 0x00007fb54536967e in g_task_return () from /usr/lib/libgio-2.0.so.0
#12 0x00007fb54591d4de in allocate_cid_ready () from /usr/lib/libqmi-glib.so.5
...
|
|
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.
|
|
|
|
All BCD-encoded strings used by MM currently have the low nybble
of each byte come before the high nybble, but some strings (such
as the EID string returned by QMI Get Slot Status) are meant to
be read in order with the high nybble before the low one. As such,
extend mm_bcd_to_string to decode both.
|
|
|
|
The "Serving System" indications reported via QMI when the device is
moving may contain LAC/TAC+CID updates or just CID updates.
E.g. this one has "CID 3GPP" (0x1e):
Mon Aug 3 11:22:42 2020 daemon.debug [1567]: [/dev/cdc-wdm0] received
generic indication (translated)... <<<<<< QMUX: <<<<<< length = 33
<<<<<< flags = 0x80 <<<<<< service = "nas" <<<<<< client = 3
<<<<<< QMI: <<<<<< flags = "indication" <<<<<< transaction =
4512 <<<<<< tlv_length = 21 <<<<<< message = "Serving System"
(0x0024) <<<<<< TLV: <<<<<< type = "Serving System" (0x01)
<<<<<< length = 6 <<<<<< value = 01:01:01:02:01:08 <<<<<<
translated = [ registration_state = 'registered' cs_attach_state =
'attached' ps_attach_state = 'attached' selected_network = '3gpp'
radio_interfaces = '{ [0] = 'lte '}' ] <<<<<< TLV: <<<<<< type
= "Data Service Capability" (0x11) <<<<<< length = 2 <<<<<<
value = 01:0B <<<<<< translated = { [0] = 'lte '} <<<<<< TLV:
<<<<<< type = "CID 3GPP" (0x1e) <<<<<< length = 4 <<<<<<
value = 14:C2:A8:00 <<<<<< translated = 11059732
And this one has both "CID 3GPP" (0x1e) and "LTE TAC" (0x25):
Mon Aug 3 11:23:05 2020 daemon.debug [1567]: [/dev/cdc-wdm0] received
generic indication (translated)... <<<<<< QMUX: <<<<<< length = 38
<<<<<< flags = 0x80 <<<<<< service = "nas" <<<<<< client = 3
<<<<<< QMI: <<<<<< flags = "indication" <<<<<< transaction =
4513 <<<<<< tlv_length = 26 <<<<<< message = "Serving System"
(0x0024) <<<<<< TLV: <<<<<< type = "Serving System" (0x01)
<<<<<< length = 6 <<<<<< value = 01:01:01:02:01:08 <<<<<<
translated = [ registration_state = 'registered' cs_attach_state =
'attached' ps_attach_state = 'attached' selected_network = '3gpp'
radio_interfaces = '{ [0] = 'lte '}' ] <<<<<< TLV: <<<<<< type
= "Data Service Capability" (0x11) <<<<<< length = 2 <<<<<<
value = 01:0B <<<<<< translated = { [0] = 'lte '} <<<<<< TLV:
<<<<<< type = "CID 3GPP" (0x1e) <<<<<< length = 4 <<<<<<
value = 32:36:BC:00 <<<<<< translated = 12334642 <<<<<< TLV:
<<<<<< type = "LTE TAC" (0x25) <<<<<< length = 2 <<<
We should therefore allow changes only in the CID, maintaining
whatever LAC/TAC value we had before.
|
|
|
|
According to QC, we should set the IP family in both the
Set IP Family and Start Network messages. After removing this
check the member is never read, only written; this means it's
effectively dead and can be removed.
|
|
Fixes a bug introduced in commit 7e386389, which caused user requested
disable operations to go to step
DISABLING_STEP_FIRST_AFTER_ENABLE_FAILED. For user requested disable,
the first step should be DISABLING_STEP_FIRST.
|
|
Telit FN980 requires more time for becoming responsive to
qmi requests after device appearance.
|
|
Querying facility locks should return a FIXED_DIALING lock if PIN2 lock
is enabled.
|
|
Prior to this CL, failure to get pin status while probing facility locks
would not flag an error. Failure to read a pin lock is a critical error
and we return it to higher layers.
|
|
DMS_UIM messages have been deprecated, and have been replaced by
equivalent UIM messages. Use UIM_GET_CARD_STATUS while querying for facility
locks if dms_uim messages were found to be deprecated.
|
|
The cleanup was missing in one of the steps.
|
|
|
|
On QMI-capable MBIM devices, also setup the SIM hot swap logic using
QMI over MBIM, so that profile changes are detected.
|
|
The SIM hot swap setup is run during initialization and if it succeeds
it must be available throughout the whole execution of this modem
object.
So, do not cleanup the SUBSCRIBER_INFO flag on 3GPP interface disable,
which is completely unrelated to the SIM hot swap setup logic.
|
|
If enabling the subscriber info notifications fails, we should no
longer have the setup for those notifications, so make sure it's
cleaned up on error.
|
|
Implement eUICC change detection for QMI based modems using one of the
following mechanisms (in order of preference):
1. If the modem supports "get slot status" operation, we monitor
physical slot status indications from the modem for the active
slot to detect when ICCID changes.
2. Use "refresh register all" to subscribe refresh indications when
the eUICC triggers REFRESH operation following the enablement of
a new profile.
3. Use "refresh register" to subscribe refresh indications (file
path of EF_ICCID is used) in a similar way. This is used with
older modems that do not support "refresh register all".
If ICCID change is detected, the already existing SIM hot swap
mechanism in MM is triggered.
|
|
This reverts commit e91f2ef315526a1a8a1b451acb5a190686b05225.
This was wrongly merged squashing multiple commits together. Reverting
to merge separate commits.
|
|
Implement eUICC change detection for QMI based modems using one of the
following mechanisms (in order of preference):
1. If the modem supports "get slot status" operation, we monitor
physical slot status indications from the modem for the active
slot to detect when ICCID changes.
2. Use "refresh register all" to subscribe refresh indications when
the eUICC triggers REFRESH operation following the enablement of
a new profile.
3. Use "refresh register" to subscribe refresh indications (file
path of EF_ICCID is used) in a similar way. This is used with
older modems that do not support "refresh register all".
If ICCID change is detected, the already existing SIM hot swap
mechanism in MM is triggered.
|
|
If the device goes away while we are listing SMS messages, it may
happen that we ask the messaging interface to take a part and the
sms list object has already been disposed. Make sure the part is freed
in that case, so that we avoid memory leaks.
==19138== 6,914 (1,232 direct, 5,682 indirect) bytes in 11 blocks are definitely lost in loss record 5,282 of 5,287
==19138== at 0x483A77F: malloc (vg_replace_malloc.c:307)
==19138== by 0x5023349: g_malloc (in /usr/lib/libglib-2.0.so.0.6600.0)
==19138== by 0x50446FF: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6600.0)
==19138== by 0x5044D6A: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.6600.0)
==19138== by 0x2577FC: mm_sms_part_new (mm-sms-part.c:180)
==19138== by 0x2504D0: mm_sms_part_3gpp_new_from_binary_pdu (mm-sms-part-3gpp.c:385)
==19138== by 0x21A15C: add_sms_part (mm-broadband-modem-mbim.c:5169)
==19138== by 0x21A31F: sms_read_query_ready (mm-broadband-modem-mbim.c:5215)
==19138== by 0x4E600F3: ??? (in /usr/lib/libgio-2.0.so.0.6600.0)
==19138== by 0x4E64638: ??? (in /usr/lib/libgio-2.0.so.0.6600.0)
==19138== by 0x4D3870D: transaction_task_complete_and_free (mbim-device.c:236)
==19138== by 0x4D396B9: process_message (mbim-device.c:616)
|
|
|
|
If we had already successfully run the sim hot swap context setup
during the initial initialization, make sure we don't re-run on SIM
PIN unlock, because we may be re-creating signal handlers and such.
|
|
The function shall be needed for profile switch checking.
|
|
If we're asking for IPv4v6 and we get IPv4-only connected, we
shouldn't attempt to provide IPv6 addressing details in the bearer
object, because we would fallback to say DHCP is needed if we were not
able to load any IPv6 details from the modem.
This is, instead of provinding both IPv4 and IPv6 details:
------------------------------------
Properties | apn: internet
| roaming: allowed
| ip type: ipv4v6
| allowed-auth: none, pap, chap, mschap, mschapv2, eap
------------------------------------
IPv4 configuration | method: static
| address: 10.182.100.233
| prefix: 24
| gateway: 10.182.100.1
| dns: 80.58.61.250, 80.58.61.254
------------------------------------
IPv6 configuration | method: dhcp
| prefix: 0
We should report only IPv4 details:
----------------------------------
Properties | apn: internet
| roaming: allowed
| ip type: ipv4v6
| allowed-auth: none, pap, chap, mschap, mschapv2, eap
----------------------------------
IPv4 configuration | method: static
| address: 10.182.100.233
| prefix: 24
| gateway: 10.182.100.1
| dns: 80.58.61.250, 80.58.61.254
|
|
If we ask for IPv4v6 is requested but the network only grants IPv4, we
end up receiving the 'Connect Set' response with nw_error set to
'pdp-type-ipv4-only-allowed'. In this case, we should still succeed
the connection attempt and only report the IPv4 info.
We therefore change the logic to skip processing the nw_error unless
the activation state is reported as ACTIVATED or ACTIVATING.
|
|
If the new iccid is already available, reading the iccid from the
card can be skipped.
|
|
Using the 'UIM switch slot' operation, this commit introduces the
ability to change which SIM slot to be active at any given time in a
Multi-SIM Single-Standby setup.
There is no validation done on whether the selected SIM slot has a
valid SIM card inserted or not; if the user selects a slot without any
SIM card, the newly probed modem object will start in Failed state
right away.
|
|
This commit introduces Multi-SIM Single-Standby support in all QMI
capable devices that support multiple SIM slots.
The 'UIM Get Slot Status' method is used to list all available
physical slots as well as the availability of SIM cards in the
different slots. This method also provides UICC already, so the SIM
objects are created early and exposed early in DBus.
Once all slots are listed, the logic will briefly make each of the
available SIM cards active in order to read additional settings like
IMSI, MCCMNC or the Operator name. This brief switching is required
because in a Single-Standby setup only one SIM can be active at any
given time.
The last slot to probe is always the one that was active originally,
making sure that the modem initialization logic can go on with the
correct SIM slot.
|
|
During the base SIM initialization process, where we ask the modem for
the properties of the currently primary active SIM, we need to make
sure that the SIM is ready before attempting to query this
information.
This explicit wait is required when loading properties for non
active SIMs during the short period of time when they're made active.
|
|
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.
Completely equivalent to mm_base_sim_new_initialized() but creating a
subclassed MMSimQmi instead of the generic MMBaseSim.
|
|
The original logic that parsed the 'UIM Get Card Status Output' did a
bit of guessing to decide what was the current lock status to consider
in the modem. This guessing was fine on systems with a single SIM
slot, but it was very wrong as soon as multiple SIMs had to be
considered.
In a Multi-SIM Multi-Standby setup, with multiple SIMs reported as
active, we should look for the one flagged as "GW primary" to consider
it the primary SIM card of the system,the one required to start a data
connection.
We explicitly ignore the ones flagged as "1X primary", as we don't
consider a SIM card required in CDMA/EVDO setups.
|
|
This is going to be used in handling the multi-SIM setup, so make it a
common helper.
|
|
This new method allows changing the SIM slot considered as primary,
when the modem supports multiple SIM slots.
The generic handling of this method will make sure that the modem
object and all its SIM objects are re-probed from scratch as soon as a
successful SIM slot switch happens.
Implementations may report MM_CORE_ERROR_EXISTS when the switch
doesn't need to happen (e.g. if the requested SIM slot is already the
active one).
|
|
When the SIM switch doesn't happen as part of an async hot swap
detection, we should trigger the switch handling at base modem level,
which e.g. doesn't require explicit cleanup of the SIM hot swap
detection port context.
|
|
The 'SimSlots' property exposes an array of SIM object paths, with one
array item for each available SIM slot in the system. If a valid SIM
card is found in a given slot, the path of the SIM object will be
exposed in the array item; if no valid SIM card is found, the empty
object path ("/") will be exposed instead.
The 'PrimarySimSlot' property exposes which of the SIM slots available
in the system is the one configured as being primary. In a Multi-SIM
Single-Standby setup, the primary slot will be the one corresponding
to the single active SIM in the system. In a Multi-SIM Multi-Standby
setup, the primary slot will be the one configured to act as primary
(e.g. the one that will be used for the data connection) among all the
active SIM cards found.
|
|
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...).
|
