NMVpnPluginInfo is little more then a wrapper around
the GKeyFile that describes the VPN plugin settings,
i.e. the name files under "/etc/NetworkManager/VPN/".
Add this class to make the VPN API more explicit. Clients
now can use NMVpnPluginInfo instead of concerning themselves
with loading the keyfile and the meaning of its properties.
Also add support for a new VPN plugins directory
"/usr/lib/NetworkManager/VPN", which should replace
"/etc/NetworkManager/VPN" in the future. But we have to
consider both locations for backward compatibility.
The content of the VPN directory is not user configuration,
hence it should not be under "/etc". See related bug 738853.
Rather than randomly including one or more of <glib.h>,
<glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
"nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
nm-glib.h, include <gio/gio.h> from there, and then change all .c
files in NM to include "nm-glib.h" rather than including the glib
headers directly.
(Public headers files still have to include the real glib headers,
since nm-glib.h isn't installed...)
Also, remove glib includes from header files that are already
including a base object header file (which must itself already include
the glib headers).
Add a file containing the defines like DBUS_INTERFACE_DBUS from
dbus-shared.h, and use it from the gdbus-using files.
Also, convert a bunch of other places that were previously hardcoding
the string values to use the defines instead, and fix the ifcfg-rh
plugin to properly namespace its own D-Bus-related defines.
Add functions nm_utils_enum_to_str() and nm_utils_enum_from_str()
which can be used to perform conversions between enum values and
strings, passing the GType automatically generated for every enum by
glib-mkenums.
If the VPN plugin terminated and the user started it again, then the
quit timer will still be running and it sometimes happens that the
VPN plugin will quit while the UI is asking the user for secrets.
That's not very nice, so don't do that.
Reproducer: while connect to the VPN, suspend your laptop. Then
resume it, and immediately re-start the VPN connection. Watch the
secrets dialog disappear within a very short time.
https://bugzilla.gnome.org/show_bug.cgi?id=752237
This is done to silence coverity. In the dispatcher the existence of the
key is checked before and we're fine with leaving the value untouched
in the vpn-plugin-old.
The property is used for controlling whether slaves should be brought up with
a master connection. If 0, activating the master will not activate slaves.
But if set to 1, activating the master will bring up slaves as well.
The property can have the third state (-1), meaning that the value is default.
That is either a value set in the configuration file for the property, or 0.
Add a 'metered' enum property to NMSettingConnection with possible
values: unknown,yes,no. The value indicates the presence of limitations
in the amount of traffic flowing through the connection.
Add a function to get a concise representation of the
device type.
libnm already has nm_device_get_type_description() for that
and it is shown by
nmcli -f GENERAL.TYPE device show
Reimplement that function for nm-core. Just take care that the
two implementations don't diverge.
The previous patch 9ffcecf86a was
completely wrong.
It tried to fix callers that provided a floating GVariant reference.
We require the caller to unref @secrets, so the correct fix it to
ensure that the reference is not floating.
Fixes: 9ffcecf86a
Fixes: 6793a32a8c
Even Fedora is no longer shipping the WiMAX SDK, so it's likely we'll
eventually accidentally break some of the code in src/devices/wimax/
(if we haven't already). Discussion on the list showed a consensus for
dropping support for WiMAX.
So, remove the SDK checks from configure.ac, remove the WiMAX device
plugin and associated manager support, and deprecate all the APIs.
For compatibility reasons, it is still possible to create and save
WiMAX connections, to toggle the software WiMAX rfkill state, and to
change the "WIMAX" log level, although none of these have any effect,
since no NMDeviceWimax will ever be created.
nmcli was only compiling in support for most WiMAX operations when NM
as a whole was built with WiMAX support, so that code has been removed
now as well. (It is still possible to use nmcli to create and edit
WiMAX connections, but those connections will never be activatable.)
(process:6888): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GDBusProxy'
Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x3149a3b224 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffda70) at gmessages.c:1046
1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt
#0 0x0000003148e50c70 in g_logv (log_domain=0x3149a3b224 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffda70) at gmessages.c:1046
#1 0x0000003148e50eaf in g_log (log_domain=log_domain@entry=0x3149a3b224 "GLib-GObject", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x3149a42690 "invalid unclassed pointer in cast to '%s'") at gmessages.c:1079
#2 0x0000003149a34171 in g_type_check_instance_cast (type_instance=type_instance@entry=0x6fc530, iface_type=<optimized out>) at gtype.c:4030
#3 0x00007ffff7d6b016 in nmdbus_settings_connection_call_get_settings_finish (proxy=0x6fc530, out_settings=out_settings@entry=0x7fffffffdbb8, res=res@entry=0x6fe150, error=error@entry=0x0)
at nmdbus-settings-connection.c:1303
#4 0x00007ffff7ce8813 in updated_get_settings_cb (proxy=<optimized out>, result=0x6fe150, user_data=user_data@entry=0x6fc650) at nm-remote-connection.c:588
#5 0x000000314a27640d in g_simple_async_result_complete (simple=0x6fe150 [GSimpleAsyncResult]) at gsimpleasyncresult.c:763
#6 0x000000314a2df47c in reply_cb (connection=<optimized out>, res=0x6fe0e0, user_data=user_data@entry=0x6fe150) at gdbusproxy.c:2623
#7 0x000000314a27640d in g_simple_async_result_complete (simple=0x6fe0e0 [GSimpleAsyncResult]) at gsimpleasyncresult.c:763
#8 0x000000314a2d48cc in g_dbus_connection_call_done (source=<optimized out>, result=<optimized out>, user_data=user_data@entry=0x7fffec01a320) at gdbusconnection.c:5502
#9 0x000000314a27640d in g_simple_async_result_complete (simple=0x6e5f40 [GSimpleAsyncResult]) at gsimpleasyncresult.c:763
#10 0x000000314a27647c in complete_in_idle_cb (data=0x6e5f40) at gsimpleasyncresult.c:775
#11 0x0000003148e49b6b in g_main_context_dispatch (context=0x687970) at gmain.c:3064
#12 0x0000003148e49b6b in g_main_context_dispatch (context=context@entry=0x687970) at gmain.c:3663
#13 0x0000003148e49f08 in g_main_context_iterate (context=0x687970, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3734
#14 0x0000003148e4a232 in g_main_loop_run (loop=0x687a80) at gmain.c:3928
#15 0x00000000004136a1 in main (argc=<optimized out>, argv=<optimized out>) at nmcli.c:632
(gdb)
When a new connection is activated and presently active connection goes away,
the active-connection-removed signal is not emitted for the old connection.
This is what happens:
1.) Initially, nm-manager::active-connections = [ActiveConnection/old]
2.) First PropertyChange is signalled for the new connection addition:
nm-manager::active-connections = [ActiveConnection/old,ActiveConnection/new]
This triggers load of ActiveConnection/new object.
3.) Another PropertyChange is signalled for the old connection removal:
nm-manager::active-connections = [ActiveConnection/new]
This removes the ActiveConnection/old object from
nm-manager::active-connections and enqueues active-connection-removed
signal. The signal is not emmitted as there's a reload from 2.) in progress.
4.) ActiveConnection/new reload finished
object_property_complete() compares
[ActiveConnection/old,ActiveConnection/new] from its odata to current
nm-manager::active-connections and incorrectly concludes that
ActiveConnection/old was just added and removes the enqueued
active-connection-removed signal.
This patch fixes the issue by remembering the original
nm-manager::active-connections property value at 2.).
[thaller@redhat.com: fixed an integer overflow and odata->array unreffing]
https://bugzilla.redhat.com/show_bug.cgi?id=1079353
When setting the certificate glib properties directly,
we raise a g_warning() when the binary data is invalid.
But since the caller has no access to the validation function,
he cannot easily check whether his action will result
in a warning. Add nm_setting_802_1x_check_cert_scheme() for
that.
