| Age | Commit message (Collapse) | Author |
|---|
|
Based on the WDS client being connected, we'll convert this error into
"IPv4 only allowed" or "IPv6 only allowed".
|
|
Just a few key translations for now.
|
|
|
|
Certain QMI or MBIM devices may not be able to support multiplexing at
all, or they may support a limited amount of links.
The new ID_MM_MAX_MULTIPLEXED_LINKS udev tag allows specifying the
maximum number of supported multiplexed links; e.g. 0 to report none
supported or 1 to report that one single multiplexed link is
supported.
|
|
Makes my compiler unhappy:
[471/539] Compiling C object src/ModemManager.p/mm-bearer-qmi.c.o
../src/mm-bearer-qmi.c: In function ‘process_operator_reserved_pco’:
../src/mm-bearer-qmi.c:580:18: warning: logical ‘and’ of equal expressions [-Wlogical-op]
580 | if (!tmp_mcc && !tmp_mcc && !container_id && !array->len)
| ^~
Fixes: f4b8d14b8d2d ('bearer-qmi: explicitly ignore PCOs with undefined contents:')
|
|
There is nothing to process in this kind of PCO fields:
<<<<<< TLV:
<<<<<< type = "Operator Reserved PCO" (0x2f)
<<<<<< length = 8
<<<<<< value = 00:00:00:00:00:00:00:00
<<<<<< translated = [ mcc = '0' mnc = '0' mnc_includes_pcs_digit = 'no' app_specific_info = '{}' container_id = '0' ]
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/690
|
|
ModemManager[562783]: <err> [1673538458.350130] mm_utils_bin2hexstr: assertion 'bin != NULL' failed
ModemManager[562783]: <dbg> [1673538458.350167] [modem0/bearer0] container ID: 0
ModemManager[562783]: <dbg> [1673538458.350201] [modem0/bearer0] app specific info: (null)
Treat it better by only trying to build the app specific info string
if there are contents in the array.
|
|
|
|
Clearly specify whether the IPv4 or IPv6 path is failing.
|
|
We're bumping the current "INFO" level messages to the new "MSG"
level, also making the new level the default.
The old "INFO" level will be used to setup an intermediate level of
logging which is not as verbose as "DEBUG" but still provides some
capabilities to analyze the behavior of a modem.
|
|
Get PCO information after the call is established
by using get runtime settings request
Register for Extended IP configuration Indication
If PCO is changed we get the indication and refetch
the pco information from modem
Send the PCO info using 3gpp_update_pco_list
|
|
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.
|
|
"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.
|
|
ModemManager handles suspend and resume signals sent from powerd
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/547
|
|
|
|
And bump libqmi to 1.31.5, which is the version introducing the rename.
|
|
|
|
The new option will change the default setting in MBIM and QMI bearers
to "request" when no explicit "multiplex" configuration is given by
the user.
This option will help test the multiplexing support in the modems
before it's made a default in a future release.
|
|
The next 1.18 release will have multiplexing support, but not enabled
by default, to avoid breaking setups that don't expect the new virtual
net interfaces for the multiplexed sessions.
The exception is Qualcomm SoCs using the IPA driver, where
multiplexing is fully required.
|
|
Using "requested" as a common default for every possible
implementation works, because it can handle setups without
multiplexing capabilities (e.g. plain AT+PPP modems) and also setups
without non-multiplexing capabilities (e.g. IPA based SoCs).
But if we don't want "requested" as default, then there will be
failing cases; e.g. we cannot use "none" as default for all as it
would break IPA, and we cannot use "required" as default for all as it
would break AT+PPP setups.
So, remove the common default, it's not flexible enough.
|
|
If the user doesn't provide a specific multiplex setting, we'll
fallback to a predefined default.
For now, the default is REQUESTED.
|
|
The original load_connection_status() method would return an
UNSUPPORTED error if connection monitoring wasn't required (which is
the default in most QMI modems).
The new reload_connection_status() method requires the check to always
be done unconditionally.
We take most of the original logic in the load_connection_status() for
the new reload_connection_status(), and we add the UNSUPPORTED error
logic exclusively in the new load_connection_status().
|
|
When we receive an indication reporting a network-initiated
disconnection, convert the QMI call end reason into a
MMMobileEquipmentError, and publish it in the new 'ConnectionError'
property.
|
|
By default, fallback to "unknown" mobile equipment error when the
modem gets disconnected by the network and we don't have any way to
know a more detailed reason.
|
|
On a failed QMI modem connection, we won't return the generic
"CallFailed" error, we'll try to convert the 3GPP verbose call end
reason to a MMMobileEquipmentError.
And if we cannot find a mapping, or if the reported error is not a
3GPP verbose call end reason, we'll return a Unknown
MMMobileEquipmentError with a string message providing detailed error
information.
|
|
|
|
Place all the logic in a separate load_settings_from_bearer() method
that takes care of propagating all bearer settings to the connect
context.
|
|
If we find that none of the requested auth settings are supported, we
should fail and return an error.
Also, make sure we set the CHAP fallback default only if either user
or password are given.
|
|
The "ready" methods for each step in the state machine must be ordered
from bottom to top, so that the readers can read the methods in that
order when following the logic.
|
|
In addition to differentiating between IPv4 and IPv6 clients, we also
need to explicitly allocate different clients in different bearer
objects when in multiplexing.
|
|
Connecting the second family of a dual stack connections fails with
'PolicyMismatch' when muxing is setup after family selection.
Switching the order of the family selection and muxing setup to
fix the problem. Looks like family selection must be the very last
WDS request before connecting the client.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
Allow plugins to specify a QmiSioPort value to bind to. This is used
e.g. in the RPMSG+BAM-DMUX setup in order to allow any RPMSG port to
control all the available net ports.
|
|
Each different plugin or protocol had a different connection attempt
value. E.g. QMI and MBIM both used 60s max for the connection attempt,
while the u-blox plugin had up to 180s for ECM based connection
setups.
This commit consolidates all plugins and protocols to use the same
timeout values for commands that may take long to respond, e.g. a
connection atempt under low signal quality conditions.
A value of 180s for the connection attempt steps and 120s for a
disconnection attempt step is considered. Note, though, that in some
cases (like a IPv4v6 setup attempt using QMI) we may have more than
one such long step, so this doesn't mean that a connection attempt
will always take less than 180s.
Users of the connection/disconnection APIs should be able to handle
the case where the attempt times out in their side (e.g. with a lower
DBus request timeout), and which would not mean the actual request
they did really failed. E.g. a connection attempt with a DBus timeout
of 30s may fail in the user with a timeout error, but the attempt
would still go on for as much as the plugin/protocol needs.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/270
|
|
Move the logic out of the base modem, and make it applicable only for
QMI modems.
|
|
According to QC, we should set the IP family in both the
Set IP Family and Start Network messages. After removing this
check the member is never read, only written; this means it's
effectively dead and can be removed.
|
|
If the connection attempt is aborted before finishing (either network
triggered or user triggered), we need to make sure that we run a 'Stop
Network' request for every 'Start Network' that had succeeded until
then, or otherwise we'll no longer be able to re-run a 'Start Network'
with the same settings and get a proper packet data handle.
E.g. in this sequence we attempt a IPv4v6 connection. The logic starts
setting up the IPv4 path:
Wed Jul 29 14:44:06 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> connecting)
Wed Jul 29 14:44:06 2020 daemon.debug [1567]: <debug> Launching connection with QMI port (usb/cdc-wdm0) and data port (net/wwan0)
Wed Jul 29 14:44:06 2020 daemon.debug [1567]: <debug> Defaulting to use static IP method
Wed Jul 29 14:44:06 2020 daemon.debug [1567]: <debug> Running IPv4 connection setup
...
The 'Start Network' for IPv4 succeeds and we get a proper packet data
handle:
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: [/dev/cdc-wdm0] sent generic request (translated)... <<<<<< QMUX: <<<<<< length = 23 <<<<<< flags = 0x00 <<<<<< service = "wds" <<<<<< client = 20 <<<<<< QMI: <<<<<< flags = "none" <<<<<< transaction = 3075 <<<<<< tlv_length = 11 <<<<<< message = "Start Network" (0x0020) <<<<<< TLV: <<<<<< type = "APN" (0x14) <<<<<< length = 8 <<<<<< value = 69:6E:74:65:72:6E:65:74 <<<<<< translated = internet
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: [/dev/cdc-wdm0] received generic response (translated)... <<<<<< QMUX: <<<<<< length = 26 <<<<<< flags = 0x80 <<<<<< service = "wds" <<<<<< client = 20 <<<<<< QMI: <<<<<< flags = "response" <<<<<< transaction = 3075 <<<<<< tlv_length = 14 <<<<<< message = "Start Network" (0x0020) <<<<<< TLV: <<<<<< type = "Result" (0x02) <<<<<< length = 4 <<<<<< value = 00:00:00:00 <<<<<< translated = SUCCESS <<<<<< TLV: <<<<<< type = "Packet Data Handle" (0x01) <<<<<< length = 4 <<<<<< value = 80:CD:AD:81 <<<<<< translated = 2175651200
Then, we start the IPv6 connection path:
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: <debug> Running IPv6 connection setup
...
But, because we suddenly are not registered in the network, the
connection is aborted, and we don't cleanup the IPv4 path at this
point, as this patch wasn't available.
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: <debug> Bearer not allowed to connect, not registered in 3GPP network
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: <debug> Forcing disconnection of bearer '/org/freedesktop/ModemManager1/Bearer/56'
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: transaction 0xe1 aborted, but message is not abortable
Wed Jul 29 14:44:07 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> enabled)
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: <debug> Couldn't connect bearer '/org/freedesktop/ModemManager1/Bearer/56': 'operation cancelled'
We then attempt a new connection request with the same settings:
Wed Jul 29 14:44:22 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> connecting)
Wed Jul 29 14:44:22 2020 daemon.debug [1567]: <debug> Launching connection with QMI port (usb/cdc-wdm0) and data port (net/wwan0)
Wed Jul 29 14:44:22 2020 daemon.debug [1567]: <debug> Defaulting to use static IP method
Wed Jul 29 14:44:22 2020 daemon.debug [1567]: <debug> Running IPv4 connection setup
And we see how the 'Start Network' command fails with a 'No Effect'
error, as the IPv4 was left connected earlier. Due to this, the modem
is assumed connected, but we won't have a valid packet data handle to
stop the connection cleanly:
Wed Jul 29 14:44:22 2020 daemon.debug [1567]: [/dev/cdc-wdm0] sent generic request (translated)... <<<<<< QMUX: <<<<<< length = 23 <<<<<< flags = 0x00 <<<<<< service = "wds" <<<<<< client = 20 <<<<<< QMI: <<<<<< flags = "none" <<<<<< transaction = 3080 <<<<<< tlv_length = 11 <<<<<< message = "Start Network" (0x0020) <<<<<< TLV: <<<<<< type = "APN" (0x14) <<<<<< length = 8 <<<<<< value = 69:6E:74:65:72:6E:65:74 <<<<<< translated = internet
Wed Jul 29 14:44:23 2020 daemon.debug [1567]: [/dev/cdc-wdm0] received generic response (translated)... <<<<<< QMUX: <<<<<< length = 26 <<<<<< flags = 0x80 <<<<<< service = "wds" <<<<<< client = 20 <<<<<< QMI: <<<<<< flags = "response" <<<<<< transaction = 3080 <<<<<< tlv_length = 14 <<<<<< message = "Start Network" (0x0020) <<<<<< TLV: <<<<<< type = "Result" (0x02) <<<<<< length = 4 <<<<<< value = 01:00:1A:00 <<<<<< translated = FAILURE: NoEffect <<<<<< TLV: <<<<<< type = "Packet Data Handle" (0x01) <<<<<< length = 4 <<<<<< value = 00:00:00:00 <<<<<< translated = 0
|
|
CHAP is almost universal nowadays, and so it is a better default
than PAP
Not changed for uBlox, that prefers an error if not specified,
and for Huawei, which uses NONE with user/pwd and has 2 CHAP choices
|
|
The QMI client version is an information provided by the QMI protocol
only when QMUX or MBIM backends are used, it won't be available when
e.g. QRTR is used. The logic in ModemManager should not rely on this
information.
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/207
|
