Use an environment variable LIBNM_GLIB_DEBUG=properties-changed to
indicate that properties-changed debugging messages should be printed.
Also cleans up the debug output formatting.
The errors were documented as org.freedesktop.NetworkManager.VPN.Error.*,
but the actual values were org.freedesktop.NetworkManager.VPN.Plugin.*
Also update the errors documentation.
The ConnectInteractive() -> Connect() fallback code doesn't work, because
_connect_internal() changes the state to NM_VPN_SERVICE_STATE_STARTING before
checking if it can implement ConnectInteractive(), and then when the Connect()
call comes in, the VPN is not in STOPPED or INIT, so it returns an error.
The commit moves setting state to STARTING after the ConnectInteractive() check
availability, in the plugin. We introduce new plugin error and set it when the
the plugin does not implement ConnectInteractive(). NetworkManager uses this
error for ConnectInteractive() -> Connect() fallback.
https://bugzilla.gnome.org/show_bug.cgi?id=708255
When the IP[46]Config changes, a new configuration gets assembled.
Before, whenever the new configuration was different than the current
one, the IP[46]Config of the device was completely replaced. This also
meant, that the old dbus IP[46]Config object was removed and the new one
was exported.
Now instead of recreating a new configuration, it updates the existing
(already exported) configuration in-place.
Also, add new gobject properties 'gateway' and 'searches' to the config class,
they will be exported over dbus.
Also, whenever any of the exported properties changes, make sure that a
notify signal gets emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=707617
Signed-off-by: Thomas Haller <thaller@redhat.com>
IPoIB "hardware addresses" are only partly based on the hardware, and
partly based on the InfiniBand configuration. So when checking if a
configuration matches a device, we should only match the fixed part.
Currently, ethernet-based VLANs can specify the hardware address of
the parent device (and, in theory, the cloned hardware address and MTU
of the VLAN device) by using an NMSettingWired in addition to the
NMSettingVlan.
The theory was that non-ethernet-based VLANs, when we eventually
supported them, would likewise use the setting type corresponding to
their parent device. However, this turns out to be both complicated
(the settings plugins and connection editor would have a
hard-to-impossible time figuring out which setting type to use in some
cases) and incorrect (for most L2 settings [eg, BSSID, bond mode,
etc], the VLAN can't have its own values separate from the parent
device).
What we should have done was just have :mac-address,
:cloned-mac-address, and :mtu properties on NMSettingVlan. However, at
this point, for backward-compatibility, we will just stick with using
a combination of NMSettingVlan and NMSettingWired, but we will use
NMSettingWired regardless of the underlying hardware type.
If you called nm_remote_connection_delete() on a connection whose only
ref was held by the NMRemoteSettings, then the callback would never
get called, because NMRemoteSettings would drop its ref before then
(when the connection emitted the 'removed' signal), so the callback
would get cancelled.
Fix this by taking an extra ref on the connection around the D-Bus
call in this case.
https://bugzilla.redhat.com/show_bug.cgi?id=997568https://bugzilla.gnome.org/show_bug.cgi?id=706141
A common case where this warning was triggered, was the removal of
IP6Config objects. As this can happen as a regular event, do not warn in
this case.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Unfortunately, $(AM_CPPFLAGS) gets overridden by per-target _CPPFLAGS
variables, which $(INCLUDES) did not, so this requires some additional
changes.
In most places, I have just gotten rid of the per-target _CPPFLAGS
variables; in directories with a single target, the per-target
variable is unnecessary, and in directories with multiple targets, the
per-target variable is often undesirable, since it forces some files
to be compiled twice, even though there ends up being no difference
between the two files.
The symbol is part of the public API (included in the GIR file),
and gjs complains loudly if a defined symbol is not found.
https://bugzilla.gnome.org/show_bug.cgi?id=706259
Acked-by: Pavel Šimerda <psimerda@redhat.com>
There are three additions to the D-Bus interface for VPN plugins as
part of this patch:
1) ConnectInteractive(): called by NM instead of Connect() to let
the plugin know that it can request additional secrets during the
connection process using SecretsRequired
2) SecretsRequired: a new signal emitted by the plugin to indicate
to NetworkManager that additional secrets are required to connect;
can only be called if NetworkManager initiated the connection by
calling the ConnectInteractive() method
3) NewSecrets(): a new method of the plugin that NetworkManager calls
when new secrets requested by the SecretsRequired signal have been
retrieved from secret agents
We need new methods because agents need to be aware of the hints that
the VPN plugins may send with the SecretsRequired signal (detailing
the specific secrets that are required) and at this time, not all
agents support passing those hints to the VPN plugin authentication
dialogs.
Add a "monitor-connection-files" config option, which can be set to
"false" to disable automatic reloading of connections on file change.
To go with this, add a new ReloadConnections method on
o.fd.NM.Settings that can be used to manually reload connections, and
add an nm-cli command to call it.
Add a new libnm-glib method to get the type description for a device,
and use it in nmcli. For most types, the type description is based on
the class name, but for NMDeviceGeneric, it comes from the
:type-description property.
Add NMDeviceGeneric, to provide generic support for unknown device
types, and create NMDeviceGenerics for those devices that NM
previously was ignoring. Allow NMSettingGeneric connections to be
activated on (managed) NMDeviceGenerics.
Use the correct annotation for vfuncs, so that NMClient.SecretAgent becomes
introspectable.
Use "self" as the first argument of the vfuncs in their declarations, to match
the actual name in nm-secret-agent.c. This avoids warnings from g-ir-scanner.
https://bugzilla.gnome.org/show_bug.cgi?id=698184
Both the VpnState property and the VpnStateChanged dbus signals update the
NMVPNConnection's 'vpn-state' GObject property, so we should ensure that
when either updates it due to a D-Bus event, GObject signals are sent
out for both too.
Though the client shouldn't be calling anything when NM isn't running
(because clients have nm_client_get_manager_running()), make sure
that NMClient never calls a NetworkManager method when NM isn't
on the bus.
Next, ensure NMObject doesn't try to refresh properties when NM isn't
running. Creating an NMClient may trigger a property refresh request,
but if NM isn't running, defer that until NM starts, to ensure that
we don't D-Bus autostart NM.
Third, ensure NMRemoteSettings doesn't attempt to list connections
unless NM is running.
This prevents service activation of NetworkManager in lieu of dbus-glib
learning about DBUS_HEADER_FLAG_NO_AUTO_START.
Use the D-Bus connection helper whenever we need a connection to
NM, which by default tries to use a private connection instead of
the shared bus connection whenever the user is root. Doing this
by default will not change the behavior of libnm-glib, and allows
tools like nmcli and libnm-glib-using clients to work in minimal
environments (those without a bus daemon) by default.
When using a private connection, we need to use dbus_g_proxy_new_for_peer()
because the bus isn't involved. Since many parts of libnm-glib create a
proxy for their corresponding remote object, consolidate the proxy creation
logic.
A later patch will add logic to use a private connection versus a bus-based
one.
A number of places in the code need to get a connection to NM through
D-Bus, and that connection could be either a shared bus connection or
a private connection. Consolidate that logic.
Unfortunately only dbus-glib >= 0.100 correctly supports private
connections (commit 8b7e4a1c4ae055864e26db4addbcc2dc38ee6963 fixes
this problem) so the private connection functionality is not enabled
for older dbus-glib versions.
It now works with sufficiently recent python 2.x or python 3.x, whatever
is the distribution default. This patch fixes 'make check' for
distributions where 'python' means python 3.x, like Gentoo.
Because _device_update_description() freed and update *both* the
vendor and product description, if the function was not able to
read one of them the first time, it would throw both away the second
time and try re-read them. That caused code like this:
vendor = nm_device_get_vendor (device);
product = nm_device_get_product (device);
to be left with a freed 'vendor' value if _device_update_description()
could not read the product when first called from nm_device_get_vendor(),
because it would be called a second time from nm_device_get_product()
and free priv->vendor and priv->product and then attempt to re-read them.
Fix this by making the function return only one value so that the
callers can control the liftime of the property they are trying to set.
==29355== Invalid read of size 8
==29355== at 0x38F7289840: __GI_mempcpy (memcpy.S:122)
==29355== by 0x38F7276F21: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1353)
==29355== by 0x38F7247DA6: vfprintf (vfprintf.c:1615)
==29355== by 0x38F7250E28: printf (printf.c:34)
==29355== by 0x41E79F: print_fields (utils.c:351)
==29355== by 0x414CAB: show_device_info (devices.c:636)
==29355== by 0x415CE8: do_devices (devices.c:1094)
==29355== by 0x41D9A9: start (nmcli.c:121)
==29355== by 0x38F6E47A54: g_main_context_dispatch (gmain.c:2715)
==29355== by 0x38F6E47D87: g_main_context_iterate.isra.24 (gmain.c:3290)
==29355== by 0x38F6E48181: g_main_loop_run (gmain.c:3484)
==29355== by 0x40CB89: main (nmcli.c:359)
==29355== Address 0x50a0401 is 1 bytes inside a block of size 18 free'd
==29355== at 0x4A077E6: free (vg_replace_malloc.c:446)
==29355== by 0x38F6E4D79E: g_free (gmem.c:252)
==29355== by 0x4C55F53: _device_update_description (nm-device.c:1417)
==29355== by 0x4C56D26: nm_device_get_product (nm-device.c:1502)
==29355== by 0x414B16: show_device_info (devices.c:620)
==29355== by 0x415CE8: do_devices (devices.c:1094)
==29355== by 0x41D9A9: start (nmcli.c:121)
==29355== by 0x38F6E47A54: g_main_context_dispatch (gmain.c:2715)
==29355== by 0x38F6E47D87: g_main_context_iterate.isra.24 (gmain.c:3290)
==29355== by 0x38F6E48181: g_main_loop_run (gmain.c:3484)
==29355== by 0x40CB89: main (nmcli.c:359)
libnm-glib's public headers include headers from libnm-util. While it
does work to just $(pkg-config --cflags --libs libnm-glib), this is
only because libnm-glib has a requires on NetworkManager which happens
to use the same include directory as libnm-util.
The correct dependency chain is thus:
libnm-glib -> libnm-util -> NetworkManager
Signed-off-by: Colin Walters <walters@verbum.org>
