Include the new SAR interface in the build so that gdbus-codegen
generates support for it in libmm-glib as well as proper documentation
in the API reference.
Add a new D-Bus interface to support dynamic SAR across multiple platforms.
The new interface exposes methods to configure sar power levels,
handle the communications with the modem, and let the platform
code be agnostic to modem type.
The g_regex_match_full() method may return FALSE without setting the
GError, so that case needs to be considered.
In addition to that, the following g_assert() was not doing what it
should have been, as it was comparing the address of the variable and
not the variable itself; rework the code to avoid that as well:
g_assert (access_tech != MM_MODEM_ACCESS_TECHNOLOGY_UNKNOWN);
The GLists maintained in the logic need to be explicitly freed (just
the lists, not the list contents) if we exit early on error or if we
end up deciding that the specific ports are available but unsupported
by the plugin (e.g. if a plugin that doesn't support net ports finds
net ports in the modem).
==225333== 24 bytes in 1 blocks are definitely lost in loss record 2,024 of 5,525
==225333== at 0x483E77F: malloc (vg_replace_malloc.c:307)
==225333== by 0x506C539: g_malloc (in /usr/lib/libglib-2.0.so.0.6600.7)
==225333== by 0x508DC8F: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6600.7)
==225333== by 0x50636B4: g_list_append (in /usr/lib/libglib-2.0.so.0.6600.7)
==225333== by 0x17E671: mm_base_modem_organize_ports (mm-base-modem.c:1298)
==225333== by 0x1E4409: mm_plugin_create_modem (mm-plugin.c:1094)
==225333== by 0x162C81: mm_device_create_modem (mm-device.c:481)
==225333== by 0x15DE60: device_support_check_ready (mm-base-manager.c:218)
==225333== by 0x4EA8173: ??? (in /usr/lib/libgio-2.0.so.0.6600.7)
==225333== by 0x4EAC6E8: ??? (in /usr/lib/libgio-2.0.so.0.6600.7)
==225333== by 0x16730F: device_context_run_ready (mm-plugin-manager.c:1533)
==225333== by 0x4EA8173: ??? (in /usr/lib/libgio-2.0.so.0.6600.7)
If using PPP, ModemManager is never in charge of deciding when the
connection is finished, because that would end up making ModemManager
try to use the TTY port while pppd is still using it.
When the modem goes unregistered for some time, we should not force
the disconnection of the bearer object, we still need to wait for pppd
to tell us the modem is disconnected.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/331
The original logic in the MBIM modem would assume that if we had more
than one network interface in the same modem, we could connect
multiple data interfaces, each one with a different session. That
logic is actually wrong, when using the master (non-multiplexed)
network interface we should always use session id 0, which is the one
holding all non-VLAN-tagged traffic.
So, remove the logic that automatically creates new bearers with a
different session id, as that is really wrong.
Also, keep track of the MMPortMbim instead of the MbimDevice directly,
because the new multiplex support will require operations on the port
as well, not only on the device.
We want to start with the data ports as clean as possible when the
modem is initialized, so we make sure the master interface is down and
that all links found are removed. This ensures a clean restart if
e.g. the daemon crashes for some other reason.
This allows us to know which of the subsystem or name for a
removed device is triggering the assertion from just a stack
trace that contains line information.
The acquisition order preference TLV must always have the same number
of elements, just the order of the elements should be different.
Also, always prefer the acquisition order preference TLV to the
GSM+WCDMA specific one, which is the same logic the modem applies.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/340
Loading capabilities is the very first step of the state machines, and
so we can rely on the "NAS Get SSP" method performed there to process
all feature checks of the SSP response.
Until now we were only considering TP/SSP unsupported if we received
a QMI protocol error (e.g. reporting unknown command).
We now also consider TP/SSP unsupported if the actual request
succeeds, but an error is reported in the response. There is no point
in considering TP/SSP supported if the plain get request without input
TLVs given fails.
Retrieve operator name from plmn_name based on current operator id.
If service name is available, use service name as operator name.
If not, use the long or short name.
Using CPOL? in the EM7345 (firmware FIH7160_V1.1_MODEM_01.1349.12)
ends up with the whole AT port stuck and non-responsive, which leads
to flagging the modem as unusable later on as soon as 10 consecutive
AT command timeouts happen.
In order to avoid that, we explicitly disable all CPOL based features
in this specific module.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/336
Before invoking AT+CPOL? for loading preferred networks list from
SIM, AT+CPOL=,2 is executed to make sure that the returned
operator codes are in expected (numeric) format.
The reset_bearer_connection() method is called during dispose, and if
a link had been created during the connection attempt, we would be
increasing the reference to the bearer object during dispose(), which
should never happen.
Just avoid passing any callback to the cleanup_link() method, as we
really were using that only for logging purposes.
In BAM-DMUX based setups we already have multiple network interfaces
exposed in the system, which we bind to using the SIO port number.
So, disable QMAP multiplexing in this case, to simplify the setup and
avoid attempting to create additional net links when connecting
multiple bearers.
The MMPortQmi may need to know very early what kind of net ports are
going to be used later on during connection, e.g. to decide what kind
of multiplexing capabilities are available and such.
So, once we have organized ports in the modem, we'll take the driver
of the first network port in the list of data ports, and pass it down
to all QMI ports setup in the modem object.
For the qmi_wwan driver, we have imposed a limitation of max 4 links
when using the add_mux/del_mux interface, because we're forced to
precreate links before multiplexing may be enabled.
When using rmnet over qmi_wwan, or rmnet over other drivers, we don't
have any limitation other than the one imposed by the WDA protocol
itself. The amount of links that may be created in this case is
1 + (QMI_DEVICE_MUX_ID_MAX - QMI_DEVICE_MUX_ID_MIN).
This information is loaded in the MMPortQmi, used to create the
MMBearerList in the QMI modem, and finally populated in the
'MaxActiveMultiplexedBearers' property of the modem interface.
The user of the ModemManager API will bring up the data network
interface exposed in the Bearer IP settings (i.e. the link interface
when using multiplexing). But for instantiated network links, we also
need to have the master interface brought up before any traffic can go
through the link interface.
We don't check whether the master interface is already up before
attempting to bring it up, we just attempt to bring it up.
If the user requests or requires to use multiplexing support, try to
create a data port link and bind the WDS client(s) to it.
If the multiplex is requested but not required, we allow link creation
failures or setups where multiplexing isn't supported; we just go on
with the default connection setup without multiplexing, as long as
there is no bearer connected on the same data network interface.
If the multiplex is required and for any reason it cannot be fully
setup, we will fail the connection attempt right away.
The data port link is created in the system via the QmiDevice in the
open MMPortQmi, but it MUST be notified by the kernel (e.g. via udev
or via kernel events) before the connection attempt goes on.
The logic to setup/cleanup net links is based on the QmiDevice net
link addition/removal operations.
When the qmi_wwan add_mux/del_mux based logic is in use, we default to
precreate 4 net links and we limit the amount of bearers that may be
connected to that maximum, because it is not guaranteed that the
qmi_wwan driver is able to create new links once the master interface
is up; and the master interface needs to be up for a proper data
connection.
For all other drivers, or when qmi_wwan uses qmap-pass-through, we
allow adding/deleting new links at any moment, without needing to rely
on the precreated ones.
When new link ports are created, the QmiDevice link management methods
try to make sure that the port exists in the system by the time the
link addition method returns, but that doesn't guarantee that the port
has also been notified by the kernel to ModemManager (e.g. via udev or
via kernel events).
This new method allows to do a explicit wait for a given port link; if
we already have it it will return right away, and otherwise we'll wait
for it to be notified via the "link port grabbed" signal.
