USB, PCI, PCMCIA... all these different system buses expose modems in
different ways. Instead of having single methods to attempt to load
different things for all these device types, detect first which is the
system bus in use, and then perform a bus-specific operation to
preload the different things.
We can just subclass the methods to check whether a given property
exists and to get it as a string, and then implement in the generic
class the actual boolean/int/hex type getters common for all.
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
Back in Linux < 3.6 days, the cdc-wdm ports exposed by the QMI driver
were flagged as owned by the 'usb' subsystem. That changed in 3.6 when
the subsystem was renamed to 'usbmisc':
https://mail.gnome.org/archives/networkmanager-list/2012-June/msg00125.html
This patch removes all monitoring of the 'usb' subsystem completely,
which is anyway a valid subsystem but for which we shouldn't need any
special handling. Right now, with newer kernels, we were using that
monitoring exclusively to get notified of full USB device remove
events, which is really not required as we already process the port
removals one by one.
We simplify the logic everywhere that attempted to match either the
'usb' or 'usbmisc' subsystems, and we no longer require the explicit
checks for the port name being named 'cdc-wdm[0-9]*' in the code, as
that is already taken care of by the ID_MM_CANDIDATE udev tag rule.
This script mock some of ModemManager DBus interfaces (main object, Modem, Sim),
it also adds a test interface "org.freedesktop.ModemManager1.LibmmGlibTest"
which allow to inject some errors and simulate behavior:
- Add a modem object
- Emit modem state changed
- Set modem error
This script also add the possibility to log in a file for debugging purpose.
Because the stdout/stderr are not shown when the program is spawned by DBus
auto activation.
Note: Script is heavily inspired from test-networkmanager-service.py from
NetworkManager project
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
The qmi_wwan driver is the only one that allows switching between
802.3 and raw-ip during runtime, and therefore we must not assume that
every QMI port managed allows to do so, we'll limit that feature only
to QMI ports in the 'usbmisc' subsystem.
For every other port, we assume the kernel expects raw-ip by default,
and so we include logic to switch the modem to raw-ip both using WDA
and CTL (WDA preferred over CTL). This assumption may not be perfect,
but it's probably a good guess, as raw-ip is the preferred and
sometimes the only format supported by new devices.
We have assumed until now that all QMI ports are based on the
qmi_wwan driver, exposed in the 'usbmisc' subsystem by the cdc-wdm
driver.
This may no longer be true, so allow creating QMI ports with
an explicit subsystem instead of defaulting always to USBMISC.
We have assumed until now that all MBIM ports are based on the
cdc_mbim driver, exposed in the 'usbmisc' subsystem by the cdc-wdm
driver.
This may no longer be true, so allow creating MBIM ports with
an explicit subsystem instead of defaulting always to USBMISC.
We have assumed until now that all QCDM ports are based on TTY
drivers, e.g. exposed via USB.
This may no longer be true, so allow creating QCDM ports with
an explicit subsystem instead of defaulting always to TTY.
Split in its own method the per-subsystem port creation mechanism, and
apply all common AT port settings (e.g. response parser, flags) in a
single place.
This check is pointless given that we're not implementing API, if
anything it should be an assert. Anyway, just get rid of it, so that
we don't need to update it on every new subsystem we add as supported.
Back in Linux < 3.6 days, the cdc-wdm ports exposed by the QMI driver
were flagged as owned by the 'usb' subsystem. That changed in 3.6 when
the subsystem was renamed to 'usbmisc':
https://mail.gnome.org/archives/networkmanager-list/2012-June/msg00125.html
So, rename the port subsystem type enumn to 'usbmisc'.
It is no longer true that all QMI ports are exposed by the qmi_wwan
driver and that all MBIM ports are exposed by the cdc_mbim driver.
There are other generic setups that allow exposing these types of
ports using different drivers, and usually we can also know the type
of port in advance via other means. Therefore, allow adding udev port
type hints for QMI and MBIM ports as well.
The rules to force ignoring certain network ports because the modem is
using some specific drivers should definitely only be applied for the
very known qmi_wwan and cdc_mbim drivers.
If network ports for QMI or MBIM modems are exposed using different
network drivers, don't ignore them.
There should be no need to do an early check to filter out ports of
the wrong subsystem.
For the user of these methods it is irrelevant if the FALSE is
returned because the port is of the wrong subsystem, or because the
test wasn't added to be probed, or because the test actually failed.
In other words, the ports where the test succeeded will only have
succeeded if they are of the correct subsystem and if the test was
actually executed successfully.
The ModemManager-names.h header file is generated on git builds, and
shipped within the release tarball, so treat it as a maintainer
managed file that should only be removed on 'maintainer-clean'.
This allows us to avoid requiring xsltproc to build release tarballs.
This is not just a rename of the rule, we also now avoid doing an
explicit check on the port name as well, and we rely on subsystem
checks only; i.e. the same logic applied for net ports.
The port candidate rules already do a 'cdc-wdm*' device name check
so it shouldn't be a big deal.
If multiple kernel device types inherit from MMKernerDevice, and those
are compared against each other, the current logic returns TRUE if the
G_OBJECT_TYPE of one of them is smaller than the other. This function is
checking for equality, so returning FALSE is enough.
The numbers associated to each port mode given by the AT^GETPORTMODE
response are not USB interface numbers, they are 'port numbers'.
Moreover, these numbers may start either at 0 or at 1, depending on
the firmware.
The only reasonable way to parse this response is to just gather the
order of all the port modes reported, and apply the modes to each
serial port found in the system in the same order.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/239
We will use one single method to apply port type hints, not a mix of
them:
* If AT^GETPORTMODE is supported, prefer its hints over any other
method.
* Otherwise, try to guess hints from USB interface descriptions.
* And if none of the plugin-specific hints are supported, we'll
default to applying generic port type hints from udev tags.
Once the hints have been applied by one of the methods above, the
fallback hint sequences are run:
* Flag the first cdc-wdm port as primary if no other port has been
flagged as primary.
* Flag the USB interface 0 as PPP if no other port type hint has
been set in any other port.
The logic applying all these procedures has been refactored so that we
have separate functions for each, which is much easier to read and
follow, even if it requires multiple iterations over the port probe
list.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/238
The mm_base_modem_get_port_*() returns a full reference, we should use
the mm_base_modem_peek_port_*() methods instead. Also, refactor a bit
the logic because both ports are really configured in the same way, so
just apply the same setup to both.
The class object definition should always be last in the file,
following the interface definitions. The actual method implementations
should be given before any other type system method (i.e. before even
the _new() method).
There is no need to reload it on every settings update attempt; just
load it once when the 3GPP interface is initialized, and re-use the
loaded value on every new update attempt.
Attempting to change the initial EPS bearer settings while in full
functionality mode shouldn't happen, so make sure we don't attempt to
do that if going into low power mode fails.
Multiple changes that shouldn't affect behavior:
* Avoid reusing the same context and state machine for the set and
the load operations, because they truly have different behaviors.
* Setup the common load operation in a separate async method, and
reuse the common operation for both the runtime state loading and
the settings configuration loading.
* Avoid having a "generic step ready" method, and instead provide
proper ready methods for each step, so that we can give
comprehensive warning logs when things fail.
* Use the common CFUN? response parser instead of a custom
implementation.
So that the list of ports shown in the Ports DBus property is also
alphabetically sorted by port name, instead of having a mess like
this:
-----------------------------
System | device: qcom-soc
| drivers: bam-dmux
| plugin: qcom-soc
| primary port: rpmsg0
| ports: rmnet5 (net), rmnet_usb0 (unknown), rmnet4 (net),
| rpmsg1 (at), rmnet3 (net), rpmsg0 (qmi), rmnet2 (net), rmnet1 (net),
| rmnet7 (net), rmnet0 (net), rmnet6 (net)
At the moment, ignored ports show up as (unknown) in the ports list
in mmcli. This makes it look like something went wrong while probing.
Actually ModemManager already tracks unknown and ignored ports separately
(MM_PORT_TYPE_UNKNOWN vs MM_PORT_TYPE_IGNORED) but the API always exposes
them as MM_MODEM_PORT_TYPE_UNKNOWN.
Add MM_MODEM_PORT_TYPE_IGNORED and use this for ignored ports so they
show up as (ignored) instead in mmcli.
Aleksander Morgado
Frederic Martinsons
Andrew Lassalle
Stephan Gerhold