Age | Commit message (Collapse) | Author |
|
This reverts commit 23033217de26fb91734fed3b999173f151195040.
This was mixed up in the wrong branch.
|
|
Based on an earlier approach from Jack Song and Nero Zhang, see
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/1050
|
|
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
|
|
There is no real need for this interface if tests are not being built.
|
|
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.
|
|
ModemManager handles suspend and resume signals sent from powerd
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/547
|
|
During mm logging, some of the information like simIccId, Telephone
numbers need to be hidden from displaying in the logs to protect
some of the user information.
Implemented for MBIM requiring libmbim 1.27.6, which is the
development version that includes the needed API.
|
|
|
|
Quick suspend/resume infrastructure for
synchronizing the interfaces when resuming.
|
|
|
|
The only purpose of this is to log what we found, nothing else, as a
quick way to detect platform support for the charsets we need.
|
|
Disables suspend/resume support at runtime.
This is useful for modems which are never turned off
or suspended when the host suspends.
|
|
Unless the generic API is explicitly allowed, as in the main.c source
file.
|
|
|
|
We have deprecated the use of MM_CORE_ERROR_CANCELLED inside the
daemon in favor of using G_IO_ERROR_CANCELLED right away, and so, we
will now register G_IO_ERROR_CANCELLED as the error mapped to the
"Cancelled" error in the ModemManager error domain in DBus.
We therefore avoid sending unknown/unmapped errors via DBus, as in
this case:
$ sudo ./test.sh
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
successfully disconnected all bearers in the modem
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
successfully disconnected all bearers in the modem
successfully disconnected all bearers in the modem
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
successfully disconnected all bearers in the modem
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
successfully disconnected all bearers in the modem
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Cancelled: Connection attempt cancelled'
successfully disconnected all bearers in the modem
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
successfully disconnected all bearers in the modem
successfully disconnected all bearers in the modem
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Cancelled: Connection attempt cancelled'
successfully disconnected all bearers in the modem
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
successfully disconnected all bearers in the modem
|
|
Added a new '--filter-policy=[POLICY]' option in the daemon, which
allows selecting between the supported filter policies. For now, only
two policies are defined:
* default: the default policy used by ModemManager, where it tries
to probe and detect as many modem ports as possible.
* whitelist-only: only devices explicitly tagged via udev (with the
ID_MM_DEVICE_PROCESS tag) will be probed and used.
|
|
And only define WITH_SYSTEMD_SUSPEND_RESUME when enabled.
We already have other systemd specific features under the
--with-systemd-* name scheme, so consolidate that, given that we don't
have any other method to support suspend/resume notifications.
|
|
This logging is available if the software was build with the configure
option --with-systemd-journal.
It will be enabled by default if libsystemd is found.
The runtime parameter --log-journal enables to output of log messages
to the systemd journal.
Please note that the journal priority field has the same value as the
syslog level so no conversion is required here.
|
|
The user can build the project passing custom CFLAGS to enable the
function location information, e.g.:
$ ./configure --prefix=/usr CFLAGS="-DMM_LOG_FUNC_LOC"
|
|
Group together all options that allow configuring the logging output,
and make them have the same --log-[XXX] prefix.
Also rework the --help output so that all option groups are printed by
default (i.e. there is no longer a --help-all option).
|
|
g_type_init() has been deprecated (and also marked with the attribute
'deprecated') since glib 2.36 as the type system is automatically
initialized. Since the minimum version of glib required by ModemManager
is 2.36, calling g_type_init() isn't necessarily in the ModemManager
code.
|
|
This commit enables a new core ModemManager daemon option, so that automatic
detection of available modems is totally disabled: '--no-auto-scan'. Note that
this option also replaces the previously used '--test-no-auto-scan' option,
which was only used during tests.
Along with the new ModemManager option, a new ReportKernelEvent() method in
the API is defined, which allows notifying the daemon of which interfaces it
should be accessing, as well as the main details of each interface. The only
mandatory parameters in the new method are 'action' (add/remove), 'name' (the
name of the interface) and 'subsystem' (the subsystem of the interface).
The mmcli tool has support for using the new api method via several new options:
* The '--report-kernel-event' option allows specifying device ports one by
one, and is a direct mapping of the ReportKernelEvent() method:
$ sudo mmcli --report-kernel-event="action=add,name=wwan0,subsystem=net"
$ sudo mmcli --report-kernel-event="action=add,name=cdc-wdm0,subsystem=usbmisc"
* The '--report-kernel-event-auto-scan' option uses udev monitoring to notify
events automatically to the daemon. This allows to operate in a way
equivalent to the default daemon operation (with implicit auto-scan).
Worth noting that the ReportKernelEvent() method is only usable when
'--no-auto-scan' is explicitly used in the daemon. An error will be reported if
the method is tried while standard udev monitoring is enabled (implicit if
auto scan isn't explicitly disabled in the daemon).
If mmcli is going to be used only to report 'real time' events, an optional
'--initial-kernel-events=[PATH]' may be given in the ModemManager call to
automatically process a set of port kernel events one by one on boot. The file
may e.g. contain:
action=add,name=wwan0,subsystem=net
action=add,name=cdc-wdm0,subsystem=usbmisc
|
|
|
|
Since commit 2d700043abc5 ("core: use g_unix_signal_add() for more
reliable Unix signal handling") we no longer have to stick to
signal-safe functions in the SIGTERM/SIGINT handler.
Use exit() to terminate so that the clean-up functions are ran and code
coverage data gets written into files.
|
|
It was actually included in the man page of the daemon, but we didn't have it.
|
|
Just so that we don't have same header names in src/ and /libmm-glib.
|
|
|
|
So that the ObjectManager interface doesn't try to signal about e.g. interface
removals; see:
https://bugzilla.gnome.org/show_bug.cgi?id=715157.
|
|
|
|
|
|
|
|
|
|
We should not automatically probe ports marked as coming from USB to serial
adapters, as we're not sure that a modem is behind the adapter. Still, let the
user request a manual scan and have these devices probed in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=647556
https://bugzilla.gnome.org/show_bug.cgi?id=691076
|
|
There were a few problems with MM's existing signal handling, first
of which was that calling g_main_loop_quit() from a signal handler
only works 50% of the time due to severe restrictions on what you
can do from the handler. This caused INT or TERM to sometimes be
ignored by MM.
Instead, use the glib signal functions which ensure that the handler
is run in the right context, where we can do anything we want.
|
|
|
|
|
|
Just in case, put a maximum time to wait for all modems to get disabled and
removed, as we don't want to wait forever.
|
|
The `MMManager' is itself also a `GDBusObjectManagerServer'. If we create this
object after having fully acquired the bus name, the client application in the
other side of the bus could be trying to use the ObjectManager interface before
we actually exported it, which is wrong. Therefore, we need to make sure that
the Manager interfaces are all exported before the name is acquired.
|
|
If the modem is started with --log-level=DEBUG, they will not be shown.
|
|
|
|
The MMManager object now derives from the gdbus-codegen-generated
MmGdbusOrgFreedesktopModemManager1Skeleton object, and implements the handlers
for the SetLogging() and ScanDevices() DBus methods.
The main program is also modified to be based on GDBus.
|
|
|
|
Make it more flexible, add logging to a file, and absolute and
relative timestamps.
|
|
More info:
https://bugzilla.redhat.com/show_bug.cgi?id=585394
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1172
dbus-glib was not properly enforcing the 'access' permissions on
object properties exported using its API. There were 2 specific bugs:
1) dbus-glib did not enforce the introspection read/write property
permissions, so if the GObject property definition allowed write
access (which is sometimes desirable), D-Bus clients could modify
that value even if the introspection said it was read-only
2) dbus-glib was not filtering out GObject properties that were
not listed in the introspection XML. Thus, if the GObject defined
more properties than were listed in the introspection XML (which is
also often useful, and MM uses this quite a bit) those properties
would also be exposed to D-Bus clients.
To fix this completely, you need to:
1) get dbus-glib master when the patch is commited, OR grab the
patch from https://bugzilla.redhat.com/show_bug.cgi?id=585394 and
build a new dbus-glib
2) rebuild ModemManager against the new dbus-glib
|
|
Distributions should set dist-version at build time with the
package version and revision, so for RPM-based distros you'd
--with-dist-version=%{version}-%{release}
which will be printed out on MM startup to help debugging.
|
|
|
|
|
|
|
|
Get rid of dependency on HAL, using libgudev instead. Fix up the plugin API
to no longer use either HAL or udev defines, but let plugins use whatever
mechanism they want for getting more information out of the device given the
subsystem and device node name.
Modems are now defined as "master" devices which "own" a one or more ports.
A port could be a serial tty device or a network device or whatever. The
plugin figures out whether it supports a given port or not and then assigns
it to a new or existing modem. Modems now have a 'valid' property that
should be set to TRUE when the modem has enough ports to operate correctly.
For devices (ex. 'hso') that use a network device for data transfer, the
modem would need to grab at least one TTY and the network device associated
with that physical device to be 'valid'.
Also move the generic modem support code to a plugin like other modem plugins,
and change the I-support-this-device mechanism to return a number indicating
the level of support. For example, the generic plugin would return a quite
low number if the device indicates via probing that it can do GSM or CDMA, but
a more specific plugin can indicate better support for the device, and thus
the more specific plugin would win control.
|
|
|