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.
"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
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.
Add a meson option -Dtests and --without-tests automake option
to disable the compilation of all available testcases.
This is useful for compiling projects with Flatpak such as
GNOME Control Center which disables all possible integrations since they
only need the DBus part of ModemManager.
Contributes to https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1392
The part generation logic is independent to whether the SMS send or
store operation failed, so just avoid doing the parts cleanup. E.g.
if we created the parts for store() but storing failed, the same parts
could still be used for send() successfully.
The internal list of parts in the base SMS object is created either
when the message is sent or when the message is stored.
The daemon should not expect the list of SMS parts to be empty upon a
store() operation requested via DBus, as the list of parts may have
already been created during send().
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/598
If the SIM swap check using ICCID or IMSI fail, don't completely fail
the operation, as the other one may still succeed.
Fail the operation only if both checks failed.
It is possible that SIM IMSI might change in roaming conditions for a sim.
Register for UIM refresh indication always and reprobe if ICCID or IMSI changes for QMI modem.
Overwrite the base class with a QMI implementation
to send DTMF characters during a call. Uses the continuous DTMF
QMI messages to support both CDMA and 3GPP networks.
Aleksander Morgado
Stephan Gerhold
Aleksander Morgado
Daniele Palmas
Pavan Holla
Aleksander Morgado
Akash Aggarwal
Dylan Van Assche
Prakash Pabba