Defining the new error codes in the headers is not enough, we also
need to add support in the error helpers in order to create proper
GErrors with the expected error codes.
The tool monitors SMS message additions and SMS state updates, e.g.:
$ sudo ./test/mmsmsmonitor
[/org/freedesktop/ModemManager1/SMS/0] sms found: received
[/org/freedesktop/ModemManager1/SMS/1] sms found: received
[/org/freedesktop/ModemManager1/SMS/2] sms found: received
[/org/freedesktop/ModemManager1/SMS/3] sms found: received
[/org/freedesktop/ModemManager1/SMS/4] sms found: received
[/org/freedesktop/ModemManager1/SMS/5] sms found: received
[/org/freedesktop/ModemManager1/SMS/6] sms found: received
[/org/freedesktop/ModemManager1/SMS/7] new sms: receiving
[/org/freedesktop/ModemManager1/SMS/7] sms updated: received
The WMC protocol was only present on older Panasonic/Verizon devices
from the 2006 - 2011 timeframe. The last device to support WMC was
the UML290 which also supported QMI (which is much more functional).
ModemManager also never used WMC support and it was never significantly
reverse engineered.
So remove WMC code from git; it'll still be in the history if anyone
cares in the future.
Remove the need to run `gtkdocize' when building from git; this should
be an operation done by the maintainer when modernizing the gtk-doc
setup (think of e.g. gettextize), no need to do it unconditionally.
This makes it easier for platforms without gtk-doc to build from git.
When trying to build with documentation enabled and gtk-doc isn't
found, we get some nice warnings and errors in the configure report:
checking for gtk-doc... no
configure: WARNING:
You will not be able to create source packages with 'make dist'
because gtk-doc >= 1.0 is not found.
checking for gtkdoc-check... no
checking for gtkdoc-check... no
checking for gtkdoc-rebase... no
checking for gtkdoc-mkpdf... no
checking whether to build gtk-doc documentation... yes
configure: error:
You must have gtk-doc >= 1.0 installed to build documentation for
ModemManager. Please install gtk-doc or disable building the
documentation by adding '--disable-gtk-doc' to './configure'.
Files generated with gtkdocize (gtk-doc) 1.25.1.
Instead of mixing both intltool and gettext, which not always work
correctly together, this patch obsoletes intltool and uses only
gettext, which includes support for translating XML files with ITS
rules.
See migration steps for GNOME projects here:
https://wiki.gnome.org/MigratingFromIntltoolToGettext
The gettext ITS rules for polkit policy files are imported from the
upstream polkit repository. We don't use the polkit-installed rule
files yet because there is no tagged release that contains those files
yet, so we cannot build-depend on any specific polkit version.
https://bugs.freedesktop.org/show_bug.cgi?id=96940
Currently, Telit's SIM swap implementation is stateless and
based on #QSS unsolicited messages 0/1 (SIM_REMOVED/SIM_INSERTED).
However, the user might have configured the modem in order to provide a
more detailed information, with #QSS values 2/3 (SIM UNLOCKED/SIM READY).
In this case and with current implementation, even receiving "#QSS: 3" will
trigger the "SIM swap" logic. The same issue might occur in other use cases
too, i.e. with SIM locked or when the message is received from both USB
ports.
This patch makes SIM swap implementation stateful, and it considers as an
actual SIM swap, only transitions from #QSS: 0 to #QSS: 1/2/3 and vice
versa.
During modem initialization we detected the flow control settings
supported by the modem, and selected the best one to use from them,
notifying it to the device via AT+IFC. The device was therefore
instructed to use that flow control setting for data transmission in
the TTY (i.e. not during AT control commands).
The missing thing was to also configure ourselves our end of the
serial port with the same flow control settings when getting into data
mode. By doing it ourselves, we avoid requiring any explicit setting
in pppd for flow control; pppd can assume the flow control settings
are already the expected ones.
Worth noting that all this setup is completely ignored for TTYs
exposed directly via USB.
https://bugs.freedesktop.org/show_bug.cgi?id=100394
Instead of relying on the udev daemon and GUDev to manage the devices reported
by the kernel, we can now run ModemManager relying solely on the kernel events
reported via the new ReportKernelEvent() API. Therefore, the '--no-auto-scan'
option is implicit for the ModemManager daemon when udev is disabled in the
build.
Additionally, a new custom implementation of the kernel device object is
provided, which uses sysfs to load the properties and attributes required in
each kernel device, instead of using a GUdevDevice.
The udev rule files are kept in place, and a simple custom parser is provided
which preloads all rules in memory once and then applies them to the different
kernel objects reported via ReportKernelEvent(), e.g. to set port type hints.
A simple unit test setup is prepared to validate the udev rules during the
`check' Makefile target.
Otherwise:
configure.ac:86: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its use is discouraged.
configure.ac:86: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead,
configure.ac:86: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your Makefile.am files.
The new tester allows to play with the AT-capable TTY using the same code as
ModemManager itself.
$ sudo ./test/mmtty -d /dev/ttyHS0 --verbose
opening serial port '/dev/ttyHS0'...
(ttyHS0) opening serial port...
(ttyHS0): port attributes not fully set
(ttyHS0) device open count is 1 (open)
flashing serial port '/dev/ttyHS0'...
ready
> AT+GCAP
(ttyHS0): --> 'AT+GCAP<LF><CR>'
(ttyHS0): <-- '<CR><LF>+GCAP: +CGSM,+DS,+ES<CR><LF><CR><LF>OK<CR><LF>'
+GCAP: +CGSM,+DS,+ES
> AT+GMI
(ttyHS0): --> 'AT+GMI<LF><CR>'
(ttyHS0): <-- '<CR><LF>Option N.V.<CR><LF><CR><LF>OK<CR><LF>'
Option N.V.
> ^C
cancelling the main loop...
(ttyHS0) device open count is 0 (close)
(ttyHS0) closing serial port...
(ttyHS0) serial port closed
(ttyHS0) forced to close port
Build all targets, except for CLI tools (mmcli, uml290), with special
flags needed for collecting code coverage information when the build has
been configured with --enable-code-coverage.
Three new targets are available in the top build directory:
- `check-code-coverage' runs the test suite and generates a code
coverage report,
- `code-coverage-capture' generates a code coverage report from already
collected data, which can come in handy when one wants to see code
paths touched by a particular test,
- `code-coverage-clean' removes the collected coverage data and the
generated reports.
This reverts commit 91898aa8b0.
See additional comments in the following bug:
https://bugzilla.gnome.org/show_bug.cgi?id=701229
Basically, 'mask' and 'unmask' operations are not the ones we should be using
or suggesting; and the Alias= for the DBus file is the correct way to go.
The '--with-polkit' configure switch now supports more options than just yes
or no:
* strict: Active user needs to explicitly authenticate when peforming an
operation defined in the Device.Control, Messaging, Location or Contacts
interfaces. Polkit policy is set to 'auth_self_keep'.
* permissive: Active user doesn't need to explicitly authenticate when
peforming an operation defined in the Device.Control, Messaging, Location or
Contacts interfaces. Polkit policy is set to 'yes'.
* none: don't use polkit.
If '--with-polkit' is not given, usage will be automatically decided based on
the presence of the Polkit headers in the system (if headers found, strict
policy will be applied, otherwise none).
Also:
* '--with-polkit' is equivalent to '--with-polkit=strict'
* '--with-polkit=yes' is equivalent to '--with-polkit=strict'
* '--with-polkit=no' is equivalent to '--with-polkit=none'
* '--without-polkit' is equivalent to '--with-polkit=none'
By default, ModemManager will always apply the strict policy, in order to
protect the user from unwanted operations in the modem (e.g. getting the PIN
locked forever after wrong PIN/PUK unlock attempts).
https://bugzilla.gnome.org/show_bug.cgi?id=701740
Avoid setting up the Alias rule, which was a helper to let us 'disable' the
systemd service including dbus-activations. Without the Alias, 'disable' will
still let starting ModemManager through dbus-activation. If you really want to
fully disallow starting MM also through dbus-activation, you should 'mask' and
'unmask' the service.
E.g.:
$ sudo systemctl mask ModemManager
ln -s '/dev/null' '/etc/systemd/system/ModemManager.service'
$ sudo mmcli -L
error: couldn't find the ModemManager process in the bus
$ sudo systemctl unmask ModemManager
rm '/etc/systemd/system/ModemManager.service'
$ sudo mmcli -L
No modems were found
https://bugzilla.gnome.org/show_bug.cgi?id=701229
It's pointless to have libmm-common around, just merge it into libmm-glib and
make ModemManager depend on libmm-glib directly. At the end, the non-common
stuff in libmm-glib is really minimal.
Aleksander Morgado
Dan Williams
Ben Chan
Carlo Lobrano
Jakub Sitnicki
Bjørn Mork
Aleksander Morgado
Christian Persch
Martyn Russell