| Age | Commit message (Collapse) | Author |
|---|
|
Seems to happen with e.g. the Fibocom FM350:
# mmcli -b 2
------------------------------------
IPv6 configuration | method: static
| address: 2607:fb90:dd16:d38a:ac39:89f1:67a7:5a9d
| prefix: 128
| gateway: 2607:fb90:dd16:d38a:ac39:89f1:67a7:5a01
| dns: fd00:976a::9, fd00:976a::10
| mtu: 1436
|
|
|
|
Rely exclusively on whether a global IPv6 was given or not, regardless
of what the DNS or gateway settings are, same as we do for IPv4.
Also, assume we only get 1 single IPv6 address. No need to have a
FIXME to add support for more addresses.
|
|
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.
|
|
Always prefer the operation error when the nw_error is not set (has
value MBIM_NW_ERROR_NONE). If the activation state is ACTIVATED or
ACTIVATING then the behavior doesn't change.
|
|
The Tethering context type UUID was defined by Microsoft in its
extensions as `5e4e0601-48dc-4e2b-acb8-08b4016bbaac` (along with
others like Admin, Xcap, App and EmergencyCalling), see
https://learn.microsoft.com/en-us/windows-hardware/drivers/network/mb-provisioned-context-operations.
These UUIDs are expected to be usable only if the modem supports
`MBIM_CID_MS_PROVISIONED_CONTEXT_V2` (CID=1) in the Basic Connect
Extensions service (3d01dcc5-fef5-4d05-0d3abef7058e9aaf).
If the modem doesn't support these, we should try to fallback to a
more generic APN type automatically, e.g. "Internet", which was
defined in MBIM 1.0 and should always be supported.
There should be no problem in a modem to have 2 separate PDN
connections with the same context type.
|
|
An explicit packet service state update request sent during a
connection attempt may end up triggering an explicit re-attach with
the network, which in turn cancels the ongoing connection attempt.
The logic to trigger an explicit attach is now managed by the
Simple.Connect() operation, which will make sure that no new request
is sent if the modem is already attached, so there is no need for this
step in the MBIM connection logic any more.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/622
|
|
The uplink and downlink speeds will be exclusively tracked via packet
service indications, and stored within the MBIM modem object.
When the bearer connect result is built, we will include the latest
speeds reported, which may have changed upon the operation to connect
to the network.
|
|
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.
|
|
|
|
Ignore the error SIM_NOT_INSERTED when ModemManager disable modem after SIM card removed
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/578
|
|
ModemManager handles suspend and resume signals sent from powerd
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/547
|
|
|
|
E.g. if the error reported by the MbimDevice is a timeout error, it
means the connection attempt is still ongoing in the device, we need
to ask it to stop.
|
|
|
|
check NwError on failure
Issue and bugfix suggestion by Aleksander Morgado.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/549
|
|
Whenever MBIMEx v3.0 is enabled, the logic should create requests and
parse responses using the updated format.
Based on an initial implementation by Som_SP <somashekhar.puttagangaiah@intel.com>
|
|
Whenever MBIMEx v3.0 is enabled, the logic should create requests and
parse responses using the updated format.
Based on an initial implementation by Som_SP <somashekhar.puttagangaiah@intel.com>
|
|
We should not set the GError as autoptr(), as we're returning it as
part of the GTask.
|
|
If the modem reports any error during the connection status check,
we're creating a GError but never disposing it. We don't need that
GError for anything, so just discard it.
|
|
|
|
During the packet service attach operation we'll get notified of which
is the agreed uplink/downlink bitrates, so include them in the stats.
|
|
|
|
|
|
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.
|
|
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.
|
|
WWAN network devices expose link management over netlink (wwan type),
but it is not yet supported by libmbim.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
|
|
We should never run any mm_bearer_properties_set_X() operations
ourselves for the properties received by the user, or otherwise the
logic comparing the bearers will fail and we may end up creating one
bearer per connection attempt.
|
|
If the user doesn't provide a specific multiplex setting, we'll
fallback to a predefined default.
For now, the default is REQUESTED.
|
|
Implement connection status reloading for MBIM based bearers.
Based on a patch by Dylan Van Assche <me@dylanvanassche.be>
|
|
|
|
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.
|
|
Instead of having a switch with a lot of cases, provide a one to one
mapping for the MbimNwError and MMMobileEquipmentError codes in an
array, and make use of the mm_mobile_equipment_error_for_code() helper
to build the actual GError.
|
|
|
|
This is now a requirement when using glib 2.56.
|
|
Unlike other implementations, with MBIM we cannot tell the modem to
connect a given profile by its profile number, which is a bit strange,
but it looks like there is no way to do that. So, if the user requests
to connect a given profile, what we do is load the profile settings by
querying the modem, and use those settings in the connect request.
|
|
If multiplexing is not supported by the network driver, do not enable
it by default and fail in case it is required.
This is the case for mhi_net driver, that do no implement multi MBIM
session (only session 0 is supported).
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
|
|
|
|
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 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.
|
|
|
|
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.
|
|
If we were requesting for IPv4v6 and we only got IPv4 reported as
activated, we would right away ignore the IPv6 bits, even if we
received IPv6 settings later on when querying for them. Change that,
so that if an IP address of a given type is received, we assume the
corresponding context was really activated even if the modem didn't
report it in the connect set response.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/320
|
|
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
MBIM modems.
|
|
If we're asking for IPv4v6 and we get IPv4-only connected, we
shouldn't attempt to provide IPv6 addressing details in the bearer
object, because we would fallback to say DHCP is needed if we were not
able to load any IPv6 details from the modem.
This is, instead of provinding both IPv4 and IPv6 details:
------------------------------------
Properties | apn: internet
| roaming: allowed
| ip type: ipv4v6
| allowed-auth: none, pap, chap, mschap, mschapv2, eap
------------------------------------
IPv4 configuration | method: static
| address: 10.182.100.233
| prefix: 24
| gateway: 10.182.100.1
| dns: 80.58.61.250, 80.58.61.254
------------------------------------
IPv6 configuration | method: dhcp
| prefix: 0
We should report only IPv4 details:
----------------------------------
Properties | apn: internet
| roaming: allowed
| ip type: ipv4v6
| allowed-auth: none, pap, chap, mschap, mschapv2, eap
----------------------------------
IPv4 configuration | method: static
| address: 10.182.100.233
| prefix: 24
| gateway: 10.182.100.1
| dns: 80.58.61.250, 80.58.61.254
|
