| Age | Commit message (Collapse) | Author |
|---|
|
|
|
There is no point in providing a configurable default IP family in the
bearer object, because we can always assume IPv4 as being the only
default expected.
Simplify the logic and also provide a new method to get the normalize
the IP family, using IPv4 as default always.
|
|
|
|
|
|
|
|
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/351
|
|
USSD is a feature interface, not critical for connection management,
so skip warning on interface enabling/disabling failures.
|
|
|
|
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
|
|
|
|
As defined in the MBIM protocol (session id 0 to 255).
|
|
|
|
These are really wrappers around the MbimDevice methods, only making
sure the MMPortMbim is open before they're used.
|
|
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.
|
|
|
|
We want the "extended_lte_band_preference" with the "nas_ssp" prefix,
as we're going to add more checks for SSP features.
|
|
operator id.
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.
|
|
|
|
|
|
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.
|
|
This step is required when using the qmi_wwan add_mux/del_mux logic,
and must be done before changing the kernel data format to raw-ip.
|
|
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.
|
|
If the port has net links that have been setup, don't allow switching
it from multiplexing mode to non-multiplexing mode.
|
|
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.
|
|
|
|
|
|
Based exclusively on sysfs for now. We could do this via netlink if
needed as well.
|
|
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.
|
