The qmi-proxy/mbim-proxy processes spawned by the daemon live in the
service's cgroup, so with the default KillMode=control-group systemd
sends SIGTERM to them at the same time as to the daemon on every unit
stop. The proxy exits immediately, tearing the control channel from
under the daemon while it is still disabling the modems:
<msg> caught signal, shutting down...
<msg> [modem0] state changed (connected -> disabling)
<msg> [modem0] port 'cdc-wdm0' no longer controllable, reprobing
<wrn> [/dev/cdc-wdm0] MBIM error: Device must be open to send commands
<wrn> shutdown failed: timeout waiting for sleep preparation to complete
The consequences of losing the proxy mid-shutdown:
- the modem disable/disconnect never reaches the device, so an MBIM
session with an active bearer is left open in the firmware (observed
to occasionally wedge the MBIM function of a Sierra EM7565 until a
firmware reset);
- the port teardown stalls waiting on the dead proxy until the
shutdown timeout, so stopping the unit always takes the full
MAX_SHUTDOWN_TIME_SECS instead of a second or two;
- the port invalidation triggers the device reprobe path in the middle
of the shutdown.
With KillMode=mixed only the daemon receives SIGTERM; the proxies
survive long enough for a clean disconnect and MBIM/QMI close, and
whatever remains in the cgroup afterwards (an idle, stateless proxy) is
killed when the unit finally stops.
Signed-off-by: Semyon Maryasin <simeon@maryasin.name>
Otherwise only Setup() method for suboptimal polling is available to
non-privileged users.
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Text messages could also be SMS
Fixes 1fb74f266 ("data: Add a policy rule to access the cellbroadcast API")
Signed-off-by: Guido Günther <agx@sigxcpu.org>
This enables the usage with busybox and strict environments.
This is related to #483 and the previous commit 91ed72aa, 02baf283.
Signed-off-by: Jongmin Kim <jmkim@debian.org>
Use our own ITS rules found under data/its. This resolves a
configuration breakage on some systems:
msgfmt: cannot locate ITS rules for data/org.freedesktop.ModemManager1.policy.in
According to the msgfmt manual, we need to specify a path to the parent
directory containing its folder. Hence, we add a path to data as the
data_dirs option.
There are cases where the user wants to configure some actions
to be run on a modem before ModemManager takes over full control.
The new "modem setup" dispatcher scripts allow running operations
in the modem after the port probing has happened and we know which
ports are usable in the device.
The scripts may e.g. change device configuration, enable modem
logging infrastructure, or any other process that would otherwise
conflict with MM's own modem management operations.
Resolves the following warning:
NOTICE: Future-deprecated features used:
* 0.64.0: {'copy arg in configure_file'}
copy arg was deprecated in meson version 0.64. Hence, use
fs.copyfile() that is also introduced in 0.64, in versions
since 0.64 and use the old approach for older versions.
Instead of creating libmm-plugin* and libmm-shared* libraries that are
dlopen()-ed on runtime, allow incorporating all plugins into the
daemon binary itself.
This makes the startup of the daemon much faster and also avoids
issues with builds that require linker namespace isolation.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/674
We are going to allow including the plugin sources built within the
ModemManager daemon binary; moving the sources within the daemon
sources directory makes it easier.
Add a meson option -Dtests and --without-tests automake option
to disable the compilation of all available testcases.
This is useful for compiling projects with Flatpak such as
GNOME Control Center which disables all possible integrations since they
only need the DBus part of ModemManager.
Contributes to https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1392
This assumes the needed modem hardware is typically not available
inside containers. If however, the local admin configures the container
to get access to the hardware in question, ModemManager can be
instructed to run in that specific container by doing:
`sudo systemctl edit ModemManager.service`
Then entering the following text in the editor:
[Unit]
# Remove condition of "not container"
ConditionVirtualization=
Upon saving/exiting, ModemManager can then be started with:
`sudo systemctl start ModemManager.service`
Signed-off-by: Simon Deziel <simon@sdeziel.info>
This allows us to not rely on bash which may not be available on
constrained systems, e.g. Yocto-built embedded systems. The scripts now
pass shellcheck.
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
The test service file is used in the test-plugin-generic unit tests,
which require the ModemManager daemon to be launched in a private test
DBus session.
Added scripts for Foxconn SDX55, Quectel EM120, and several old Sierra
Wireless manufactured devices:
* Installed but not used by default, the user needs to setup manual
links from ${pkgdatadir}/fcc-unlock.available.d, to
${pkgsysconfdir}/fcc-unlock.d in order to enable them.
* Installed with rights only for the owner, so that the dispatcher in
ModemManager can validate them.
* They rely on $PATH to find the qmicli/mbimcli tools.
In addition to these scripts, per-vid:pid links are created in the
same ${pkgdatadir}/fcc-unlock.available.d directory, specifying which
are the specific devices that require the FCC unlock operation.
This patch also creates the ${pkgsysconfdir}/fcc-unlock.d and
${pkglibdir}/fcc-unlock.d directories where ModemManager looks for the
enabled tools.
Note that the meson setup doesn't support creating/deleting links
officially yet, so we use a workaround using meson.add_install_script
that is not perfect (i.e. doesn't handle the symlink removal during
uninstall). See https://github.com/mesonbuild/meson/issues/1602
meson is a build system focused on speed an ease of use, which
helps speeding up the software development. This patch adds meson
support along autotools.
With the recently added support for modems using QRTR, ModemManager
needs to have access to the corresponding address family so it can
interact with the modem.
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
This interface will provide support for the profile management
operations in different modem types.
This initial commit introduces support for the interface and provides
handlers for the methods that may be called in the interface.