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.
We will grab the ports and make them available through find_ports() or
peek_port() or get_port().
The link ports are not 'organized' so they won't be available in
e.g. get_data_ports(), which is fine, because we don't want to mix
them with the real data ports exposed by the device.
Link port additions and removals are also notified via signals in the
modem object, so that explicit wait for specific ports can be done.
We can now setup a 'lower device' object that will be the one
providing all physdev info. This is useful when using virtual ports
that refer to a 'lower' real physical device, in order to bind
together all those ports on the same modem object.
We now allow requesting for multiplex support in the set data format
operation of the MMPortQmi.
If multiplexing is supported, we'll configure both the modem (link
layer protocol and data aggregation protocol) and the kernel expected
data format (if qmi_wwan in use).
The logic adds additional preferences over the different choices we
may find in the logic:
* In newer modems, by default QMAPv5 is preferred over QMAP as data
aggregation protocol.
* If using qmi_wwan, by default rmnet (qmap-pass-through) is
preferred over add_mux/del_mux (raw-ip) kernel expected data
format.
These preferences are only considered if the specific support is found
in the setup.
Whenever we change the multiplexing support, an internal port reset
operation will be run, in order to bring the state of the setup to a
clean known one.
If the daemon boots and it finds already existing modems in the
system (i.e. not hotplugged), we will attempt to reset all QMI/NET
ports, so that the state in which the ports are is a known one.
This logic allows us to cleanup any possible existing network link if
e.g. the daemon crashes and is restarted by the system.
The port reset operation will attempt to setup the QMI and associated
NET ports to the same state as they has when the modem was originally
detected: no mux links, net interface down and (for the qmi_wwan based
devices) expected kernel data format set to 802.3.
By default, the external calls to the port reset logic will require
the port to be closed (i.e. no internal QmiDevice), so a new temporary
QmiDevice will be created just for this operation. The new QmiDevice
doesn't even need to be open, as the reset operations just uses the
device to attempt to remove net links.
The internal call to the port reset logic uses an input QmiDevice
which may be the newly allocated one in the external call, or the
internal QmiDevice, if there is one.
Right now just with the support to setup link properties like up/down
state or the link mtu.
This features are required when using QMAP based multiplexing with the
qmi_wwan kernel driver.
The new logic is implemented as a separate async method with its own
state machine, which allows selecting different data format setups
with an strict preference.
Until now, we would not attempt to re-configure the link layer
protocol in the modem interface if we could instead change the
expected data format in the kernel. E.g. a MC7304 exposing one
interface in 802.3 format and another one in raw-ip format would be
used in either 802.3 or raw-ip, depending on the network interface
being connected.
This logic changes now, and we now by default always prefer raw-ip
over 802.3. E.g. the same MC7304 would now always be used in raw-ip
mode, regardless of whether the interface was by default in raw-ip or
not. Obviously, raw-ip will only be used if the kernel data format can
be changed. If the qmi_wwan driver in use is older than 4.5, the
default link layer protocol attempted would be 802.3, if the modem
supports it.
In addition to this change in logic, we also now avoid setting up the
WDA data format as soon as the port is opened; instead we defer that
logic until a connection request arrives, because once QMAP support is
integrated, we'll need to know whether the user requested the
multiplexing support or not. Therefore, during port open we just
query current state and during the connection attempt we reconfigure
either modem or kernel or both.
If WDA is unsupported, the logic falls back to CTL-based link layer
protocol configuration, as it use to.
The logic now also supports WDA Set/Get Data Format operations with
the newest modems that require the explicit endpoint info TLV. As soon
as the first failure is reported asking for the endpoint TLV, we'll
flag the port as requiring the endpoint info always.
The endpoint info of a given MMPortQmi is immutable (it's associated
to the specific kernel driver in use and to the specific physical
interface number of the device).
We'll load it as soon as the kernel device object is set in the port,
and we'll keep it in the private struct so that it can be used at any
time, e.g. by the WDA Get/Set Data Format operations on newest
devices, where the endpoint info TLV is mandatory.
This property will be TRUE if the bearer has the data session
connected through a multiplexed interface.
If the bearer is disconnected, or connected without multiplexing, the
property will report FALSE.
In addition to the amount of bearers a user may connect without
multiplexing enabled (the default until now), we now also expose the
maximum number of bearers a user may connect after enabling
multiplexing over one single network interface (if supported).
The method responsible for creating the MMBearerList is now also
subclassable, so that implementations supporting multiplexing can
provide their own version with their own thresholds.
This property was never initialized with a correct value, we would
always use the same value as used for MaxActiveBearers, which isn't
technically right. Just suggest to ignore this property, and flag
it as deprecated.
In addition to deprecating the API property, we will internally no
longer limit the amount of bearer objects that may be created with
different connection settings. The bearer object exposed in DBus is a
representation of the connection that may be setup, and so we can hold
as many representations as we want as long as the amount of connected
bearers doesn't exceed the maximum amount for each modem.
Leaving around the disconnected modems also serves another purpose.
Each bearer holds information about the amount of times a connection
with it has been attempted, and the amount of data transferred through
it. If we use the Simple.Connect() method to connect the modem using
different bearer settings, we won't lose the information of the past
connection attempts with different settings.
Both the Simple.Connect() and Modem.CreateBearer() are updated to
allow a new 'multiplex' setting in the properties provided by the user
in both of these methods.
The new setting expects a MMBearerMultiplexSupport enum indicating
what kind of multiplex needs the user has:
* none: if multiplex must not be used.
* requested: if multiplex should be used if available.
* required: if multiplex must be used.
The underlying implementations will take care of accepting or
rejecting the setting depending on the system and modem capabilities.
Before reading preferred network list with AT+CPOL?, AT+CPLS=0 is
now invoked first to make sure that the correct PLMN list (i.e.
user-defined) is selected.
