Multiplexing currently does not work correctly for BAM-DMUX because
ModemManager reuses the same WDS client for all data points. A second
bearer can be created but it effectively disables the first one.
Fix this similar to the existing checks for the mux-id by including the
endpoint type and number in the QMI client flags.
At the moment the endpoint type/number is chosen based on the QMI
control port. The assumption is that multiplexing is implemented using
an additional protocol layer (e.g. QMAP) or that each network interface
has its own QMI control port.
This is not necessarily the case for BAM-DMUX. To use the built-in
multiplexing the WDS client must be bound to the correct data port.
This works already for older firmware versions using "Bind Data Port"
(SIO port numbers), but not for newer ones using "Bind Mux Data Port"
(endpoint type/interface numbers).
Make it work for newer firmware versions as well by choosing the
endpoint type/number based on the data port similar to the existing
implementation for SIO port numbers.
Note: The correct endpoint interface number is currently only used for
the steps in mm-bearer-qmi. Ideally more refactoring should be done in
mm-port-qmi to call WDA Set Data Format for each of the endpoints.
In practice it usually works fine without because the data format is
set correctly by default.
Now that peek_port_qmi_for_data_mhi() is a separate function it becomes
obvious that it looks different from all the others: There is no check
that a QMI port was actually found.
Add it similar to the one used for qmi_wwan.
peek_port_qmi_for_data() is currently quite confusing to read because it
mostly covers qmi_wwan while the mhi_net case returns early. Split this
up into separate functions per driver to make it less confusing, similar
to the variant in mm-broadband-modem-qmi-qcom-soc.
No functional change.
mm_broadband_modem_qmi_peek_port_qmi() already looks up a QMI port
exactly the same way it is implemented in the BAM-DMUX variant of
peek_port_qmi_for_data(), so we can just reuse it to simplify the code.
No functional change.
"Bind Data Port" does not work correctly on newer platforms with
BAM-DMUX (e.g. MSM8909). It returns "device unsupported" even for
valid SIO port numbers.
As an alternative, it seems to be possible to use the newer "Bind *Mux*
Data Port" instead. This works even when QMAP multiplexing is disabled
(using WDA "Set Data Format"). In this case the mux-id seems to be
entirely ignored and can be a dummy value such as MUX_ID_UNBOUND.
Implement this by checking for the error code of "Bind Data Port"
and fallback to "Bind Mux Data Port" instead.
The important part in this case is that the endpoint type and interface
number are set correctly. At the moment this works only for the "wwan0"
interface because the endpoint information is currently maintained
globally as part of the QMI control port instead of being handled
separately per data/net port. Further refactoring is needed to enable
multiplexing on these platforms.
At the moment the endpoint type and number for the QMI WDA calls are
chosen based on the subsystem of the QMI control port. This does not
work correctly for some configurations:
- SUBSYS_QRTR currently implies ENDPOINT_TYPE_EMBEDDED, but this is
only valid for QRTR+IPA configurations. For QRTR+BAM-DMUX the
correct type is ENDPOINT_TYPE_BAM_DMUX.
- SUBSYS_WWAN currently implies ENDPOINT_TYPE_PCIE, but there is
already a comment that mentions that this selection works only for
MHI/PCIe modems. SUBSYS_WWAN is also used by RPMSG+BAM-DMUX
configurations in which case the correct type is also
ENDPOINT_TYPE_BAM_DMUX.
Looking closer at these cases suggests that the endpoint type actually
refers to the data/net port and not the control port. It is more
reliable choose it based on the network driver and not the subsystem
of the control port.
Address this partially by choosing the endpoint type based on the
net_driver. Choosing the endpoint interface number correctly requires
more refactoring since most of the logic is currently handled globally
for a QMI control port, while it's actually specific to the chosen
data/net port in some cases (e.g. multiple BAM-DMUX network interfaces).
Since 1.18 the user can request a different APN type during the
connection attempt, which translates into a different context type in
the actual MBIM Connect Set request. Therefore, the context type of a
given connection is no longer always INTERNET.
Matching by the session id to report disconnections should be more
than enough, which also helps to cover the case where the modem
doesn't report the original context type used during the
attempt (e.g. reporting NONE unconditionally).
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/614
This commit fixes memory leaks that occur when invoking
mm_modem_3gpp_profile_manager_list function.
When processing the connection profile data retrieved from dbus
in build_list_results function, the iterator data (of GVariant type)
were not properly freed after use in the while loop.
==7903== 2,697 (144 direct, 2,553 indirect) bytes in 3 blocks are definitely lost in loss record 2,525 of 2,538
==7903== at 0x484086F: malloc (vg_replace_malloc.c:381)
==7903== by 0x4A13938: g_malloc (gmem.c:106)
==7903== by 0x4A2B1F4: g_slice_alloc (gslice.c:1069)
==7903== by 0x4A51322: UnknownInlinedFun (gvariant-core.c:486)
==7903== by 0x4A51322: UnknownInlinedFun (gvariant-core.c:624)
==7903== by 0x4A51322: g_variant_builder_end (gvariant.c:3718)
==7903== by 0x4C2FEC1: parse_value_from_blob.isra.0 (gdbusmessage.c:1866)
==7903== by 0x4C2FE8F: parse_value_from_blob.isra.0 (gdbusmessage.c:1766)
==7903== by 0x4C2FF37: parse_value_from_blob.isra.0 (gdbusmessage.c:1850)
==7903== by 0x4BF93A7: g_dbus_message_new_from_blob (gdbusmessage.c:2226)
==7903== by 0x4C09334: _g_dbus_worker_do_read_cb (gdbusprivate.c:750)
==7903== by 0x4B9EA79: g_task_return_now (gtask.c:1219)
==7903== by 0x4B9EABC: complete_in_idle_cb (gtask.c:1233)
==7903== by 0x4A0774A: g_idle_dispatch (gmain.c:5848)
Signed-off-by: Louis-Alexis Eyraud <louis-alexis.eyraud@unabiz.com>
The log level of the libraries was not honoring the log level
configured in MM, so we would see debug messages reported even if the
default log level configured was INFO or MSG.
The format of the logs emitted by the libraries was also not following
the format of the rest of MM logs, e.g. they would not include timing
info in the logs which would make it hard to follow certain event
transitions.
Make the libraries logging use the ModemManager logging method, to fix
all those issues.
The SIM slots ptr array should have a proper GDestroyNotify, so that
whenever the array is unref-ed as part of the modem disposal logic,
the SIM objects (and the modem object references they keep) are also
unref-ed.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/571
We provide a consolidated method to update the PS/EPS/5GS registration
states, based on the actual state reported via NAS and the availabiity
or not of the DSD data RAT.
On this consolidated method, we now force the IDLE state for every
case where it would have been HOME/ROAMING if the data RAT reported
via the DSD service is unknown. This includes not only transitions
into the HOME/ROAMING state, but also transitions to unknown data RAT.
"registered" state should not wholly depend on the PS/EPS/5GS domain
state reported by NAS.
It should listen to DSD system status for availabilty of data network
at modem before moving to 'registered' state".
A failure loading IMSI or ICCID (unless for the UNSUPPORTED case)
could be an indication that there is no SIM.
Ideally, the logic checking if a SIM swap happened should have checked
first if there is a SIM card in the slot, and only if there is one go
on to try to load IMSI or ICCID.
Modem/SIM implementations that keep cached info that is not supposed
to change during runtime of a modem may need to be notified about when
a suspend/resume has happened, so that they can clear and reload the
internally cached data.
