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.
Tests had either their own g_print()s or they would enable a _mm_log() method to
get all g_debug()s from the libraries printed. In order to cleanup the result of
the tests run, avoid this stdout dumps by default, and only enable them if
explicitly enabled in CFLAGS, e.g.:
$> ./configure CFLAGS="-DENABLE_TEST_MESSAGE_TRACES"
Old python tests using the old ModemManager interface are removed, as mmcli
provides already a much nicer way to test the DBus interface.
Also, mm-test.py and the PPPD plugin get removed, which were also using the old
interface, and which were not very useful for testing newer non-PPP based
modems.
https://bugzilla.gnome.org/show_bug.cgi?id=702061
Some modems do require it, but some others won't (e.g. CDMA based ones), so
just make the operation optional, but only if the modem replies NoDeviceSupport.
https://bugzilla.gnome.org/show_bug.cgi?id=702419
It is quite common to have modems handled with QMI but with very limited
services implemented, e.g. without WMS:
[/dev/cdc-wdm0] QMI Device supports 5 services:
[/dev/cdc-wdm0] ctl (1.3)
[/dev/cdc-wdm0] wds (1.5)
[/dev/cdc-wdm0] dms (1.2)
[/dev/cdc-wdm0] nas (1.0)
[/dev/cdc-wdm0] cat (0.0)
We'll now fallback to use plain AT commands when no QMI WMS service is found.
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 sometimes provides a much better view of the supported modes than the WS46=?
command, which is not always properly implemented. E.g.:
Nokia N950:
---------------
at+ws46=?
(12)
OK
at*cnti=2
*CNTI: 2,GSM,GPRS,EDGE,UMTS,HSDPA,HSUPA
OK
Sierra AC313u
---------------
at+ws46=?
ERROR
at*cnti=2
*CNTI: 2,GSM,GPRS,EDGE,UMTS,HSDPA/HSUPA,HSPA+,LTE
OK
We may be asking to load supported modes while in locked state, so the commands
may fail. In order to re-load them properly once we're unlocked, we better just
return an error instead of setting defaults.
We won't allow changing modes or bands through Simple.Connect(). Applications
should instead look at the corresponding SupportedBands or SupportedModes, and
then use SetCurrentBands() or SetCurrentModes() explicitly.
Changes being:
* Don't rely on the band preference TLVs presence. The band preference TLVs are
always given, even if the modem doesn't support the specific capability right
away. E.g. a GSM/UMTS/LTE modem configured with 'gsm-umts' capability (no
'lte') still shows the LTE band preference TLV in the SSP responses.
* Don't automatically add LTE as current capability. We needed this when we
were not able to change capabilities, so that we didn't lose the ability to
set 4G mode as allowed.
And also make it a list of masks, specifying which are the specific combinations
supported, not just one mask with all.
E.g.:
-------------------------
Hardware | manufacturer: 'Sierra Wireless, Incorporated'
| model: 'MC7710'
| revision: 'SWI9200X_03.05.19.04ap r5475 carmd-en-10527 2012/09/17 17:57:14'
| supported: 'gsm-umts
| gsm-umts, lte'
| current: 'gsm-umts, lte'
| equipment id: '358178040668164'
We now have a single 'CurrentModes' property which contains both values in a
tuple with signature "(uu)".
Also, rename 'SetAllowedModes()' to 'SetCurrentModes()', and update the list of
arguments expected to have a single "(uu)" tuple.
