The qmi_wwan driver is the only one that allows switching between
802.3 and raw-ip during runtime, and therefore we must not assume that
every QMI port managed allows to do so, we'll limit that feature only
to QMI ports in the 'usbmisc' subsystem.
For every other port, we assume the kernel expects raw-ip by default,
and so we include logic to switch the modem to raw-ip both using WDA
and CTL (WDA preferred over CTL). This assumption may not be perfect,
but it's probably a good guess, as raw-ip is the preferred and
sometimes the only format supported by new devices.
We have assumed until now that all QMI ports are based on the
qmi_wwan driver, exposed in the 'usbmisc' subsystem by the cdc-wdm
driver.
This may no longer be true, so allow creating QMI ports with
an explicit subsystem instead of defaulting always to USBMISC.
We have assumed until now that all MBIM ports are based on the
cdc_mbim driver, exposed in the 'usbmisc' subsystem by the cdc-wdm
driver.
This may no longer be true, so allow creating MBIM ports with
an explicit subsystem instead of defaulting always to USBMISC.
We have assumed until now that all QCDM ports are based on TTY
drivers, e.g. exposed via USB.
This may no longer be true, so allow creating QCDM ports with
an explicit subsystem instead of defaulting always to TTY.
Split in its own method the per-subsystem port creation mechanism, and
apply all common AT port settings (e.g. response parser, flags) in a
single place.
This check is pointless given that we're not implementing API, if
anything it should be an assert. Anyway, just get rid of it, so that
we don't need to update it on every new subsystem we add as supported.
Back in Linux < 3.6 days, the cdc-wdm ports exposed by the QMI driver
were flagged as owned by the 'usb' subsystem. That changed in 3.6 when
the subsystem was renamed to 'usbmisc':
https://mail.gnome.org/archives/networkmanager-list/2012-June/msg00125.html
So, rename the port subsystem type enumn to 'usbmisc'.
It is no longer true that all QMI ports are exposed by the qmi_wwan
driver and that all MBIM ports are exposed by the cdc_mbim driver.
There are other generic setups that allow exposing these types of
ports using different drivers, and usually we can also know the type
of port in advance via other means. Therefore, allow adding udev port
type hints for QMI and MBIM ports as well.
The rules to force ignoring certain network ports because the modem is
using some specific drivers should definitely only be applied for the
very known qmi_wwan and cdc_mbim drivers.
If network ports for QMI or MBIM modems are exposed using different
network drivers, don't ignore them.
There should be no need to do an early check to filter out ports of
the wrong subsystem.
For the user of these methods it is irrelevant if the FALSE is
returned because the port is of the wrong subsystem, or because the
test wasn't added to be probed, or because the test actually failed.
In other words, the ports where the test succeeded will only have
succeeded if they are of the correct subsystem and if the test was
actually executed successfully.
This is not just a rename of the rule, we also now avoid doing an
explicit check on the port name as well, and we rely on subsystem
checks only; i.e. the same logic applied for net ports.
The port candidate rules already do a 'cdc-wdm*' device name check
so it shouldn't be a big deal.
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.