If multiple kernel device types inherit from MMKernerDevice, and those
are compared against each other, the current logic returns TRUE if the
G_OBJECT_TYPE of one of them is smaller than the other. This function is
checking for equality, so returning FALSE is enough.
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.
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).
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.
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.
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 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.
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.
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.
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 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.
Aleksander Morgado
Andrew Lassalle
Stephan Gerhold
Eric Caruso
Pavan Holla
Daniele Palmas
Teijo Kinnunen