Even if udev support is really built and available.
This is extremely useful to test the udev-less setup without fully
recompiling the whole daemon.
E.g.: the daemon can be run like this:
$ sudo /usr/sbin/ModemManager --debug --test-no-udev
And then, the kernel events may be reported using mmcli like this:
$ sudo mmcli --report-kernel-event-auto-scan
Instead of the custom simple implementation which only supported the
'*' modifier in the pattern. This allows us to support e.g. attribute
value matches like e.g. 'DATA[0-9]*_CNTL'.
Until now we did not support ATTRS{} matches against attributes we
don't support in the core codebase. Implement now a simple lookup
mechanism which traverses the tree of sysfs path from the port sysfs
path to the physical device sysfs path, looking up the attribute
requested.
This is not completely equivalent to what udev does, because the udev
rules matching ATTRS would usually also include an additional previous
matching e.g. SUBSYSTEMS and such, so that the ATTRS is looked up
exactly in the device that also matches the additional previous
rules. In our case, we just simplify the logic and return the first
one found.
We were applying the DRIVERS check looking only at the single port
driver. Instead, we now lookup and cache all drivers found in the
device tree, and apply the loose DRIVERS check properly looking at all
of them.
We were applying the SUBSYSTEMS and SUBSYSTEM check looking at the
sysfs path and just hoping the subsystem we're looking for is included
in the path itself. Instead, we now lookup and cache all susystems
found in the device tree, and apply the loose SUBSYSTEMS check
properly looking at all of them.
E.g. we can now match SUBSYSTEMS="mhi_q" in the following device tree,
without needing it to be found in the sysfs path:
looking at device '/devices/pci0000:00/0000:00:1b.0/0000:01:00.0/1001_00.01.00_MBIM/mhi_uci_q/mhi_MBIM':
SUBSYSTEM=="mhi_uci_q"
looking at parent device '/devices/pci0000:00/0000:00:1b.0/0000:01:00.0/1001_00.01.00_MBIM':
SUBSYSTEMS=="mhi_q"
looking at parent device '/devices/pci0000:00/0000:00:1b.0/0000:01:00.0':
SUBSYSTEMS=="pci"
The generic backend implementation was really based on detecting USB
devices, not so much devices in other subsystems. This patch puts the
generic backend at the same level as the udev backend to support
non-USB modems.
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.
