NetworkManager[31624]: <warn> VPN service 'openvpn': could not launch the VPN service. error: (8) Failed to execute child process "/usr/local/libexec/nm-openvpn-service" (No such file or directory).
**
NetworkManager:ERROR:nm-manager.c:3094:_activation_auth_done: assertion failed: (error)
An sd_dhcp_lease will always have an associated address, netmask, and
lifetime, so we don't have to check for errors when fetching them.
(The systemd code will fill in a default netmask if the server didn't
provide one; nm-dhcp-systemd's code to do that itself was redundant
and unused.)
Also, log the expiration time and NTP servers, for consistency with
everything else.
If asked to read a file that doesn't exist, sd_dhcp_lease_load()
returns 0 (success) without setting the out lease argument. So we need
to check both the return status and the lease before proceeding.
The signals might be delivered in no particular order and we need to wait for
the device to reach stable state (whether it's successfully conntected or not)
as well as the active connection to leave ACTIVATING state.
https://bugzilla.gnome.org/show_bug.cgi?id=740320
Fixes testing on 32-bit arches:
/core/general/test_setting_compare_timestamp:
(./test-general:29331): GLib-GObject-WARNING **: g_object_set_valist: object class `NMSettingConnection' has no property named `$?\xff\xff\x89t$0\x89|$4\xe8\u001c\x98\xff\xff\x85\xc0tM\x83\xf8\xfft3\x8dT$(\xc7D$\u0008'
/bin/sh: line 5: 29331 Trace/breakpoint trap ${dir}$tst
FAIL: test-general
Fixes: 093a3c88d0
We were refreshing the list when the set of available devices changed,
or the set of active connections changed, but not when the set of
available connections changed.
https://bugzilla.gnome.org/show_bug.cgi?id=740333
Since libnm-core secret-flags properties are now enum-typed rather
than just being uints, we can now actually recognize them when
generating docs, rather than just assuming that every property whose
name ends in '-flags', but isn't in NMSettingDcb, is a secret-flags
property.
Now that nm-setting-docs.xml is more D-Bus-specific, it's less
appropriate for nmcli's internal documentation. So generate a second
copy of the docs without using the overrides file, and use that one
for nmcli's documentation.
Add "---dbus---" sections to the NMSetting property docs, in the same
style as the plugin docs, parse them out into a file
"nm-setting-docs-overrides.xml", and use them to override the GObject
property docs in nm-setting-docs.xml.
This lets us put more D-Bus-specific information in the setting docs,
without cluttering up the property docs, and it also lets us document
dbus-only properties.
Add nm_setting_get_dbus_property_type(), and use this to get the
correct type for properties in nm-seting-docs.xml, in situations where
the D-Bus and GObject property types don't match.
In the case of enum/flags-valued properties, give both the enum name
and the underlying D-Bus type.
Each GBytes-valued property was using
_nm_setting_class_transform_property() to register a GBytes<->'ay'
transform. So just build that rule into the generic machinery in
nm-setting.c.
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
Not invoking a callback when cancelling the operation is counter
intuitive.
Note that NMPolicy refs the device, cancelling the call would leave
the reference hanging. That was not an issue because the call was
never cancelled. But still the behavior of NMFirewallManager is
unexpected.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The directory firewall-manager/ only contained one source and one
header file. Move them to the parent src/ directory.
Signed-off-by: Thomas Haller <thaller@redhat.com>
NMIP4Config/NMIP6Config have their own NMIPRoute->D-Bus conversion
code since the code in libnm-core is gdbus-specific. But they were
doing it wrong, resulting in clients seeing a next hop of 0.0.0.0/::
for all routes.
Left over from a previous version of the iface helper patches and was
never removed when NM_IFACE_HELPER was removed. Since NM_IFACE_HELPER
wasn't defined, this code was already always compiled.
The kernel does not terminate an ongoing IPv6LL address process when
the IPv6LL address generation mode is set to 'none' (indicating that
userspace wishes to handle IPv6LL). Next, NetworkManager does not
expose IPv6 addresses internally until they have completed DAD. This
means that the kernel may still be performing DAD for an IPv6LL
address when NetworkManager turns userspace IPv6LL on, and when
DAD is complete NetworkManager will finally pay attention to the
address. If the device is in the DISCONNECTED state, NetworkManager
will then generate and assume an IPv6LL-only connection on the device.
Unfortunately, that behavior happens if the following is true:
1) IPv6LL addressing takes a while (eg, dad_transmits is high or
the kernel takes a while for some reason)
2) the activated connection fails quickly (dhclient fails or some
other fatal error terminates the activation attempt)
3) the activated connection has ipv6.method=ignore
In this case, when the device was brought up and ipv6.method=ignore,
NetworkManager re-enabled kernel IPv6LL and reset the IPv6 sysctl
properties. The kernel then generated an IPv6LL address and began
DAD. dhclient failed quickly, and NM deactivated the device. NM
then turned off kernel IPv6LL when deactivating the device, but the
kernel does not terminate the ongoing DAD. Some time after the device
entered the DISCONNECTED state, the kernel finished DAD and that
allowed NetworkManager to internally see the address, which caused
NetworkManager to emit the 'recheck-assume' signal. This
generated a new IPv6LL-only connection which was then assumed.
Bouncing 'disable_ipv6' when re-enabling userspace IPv6LL during
device deactivation flushes the tentative kernel IPv6LL address,
thus preventing the address from being announced after userspace
IPv6LL is re-enabled. The other alternative is to expose
tentative addresses (eg those still doing DAD) in NMPlatform so
they would be flushed when the device deactivates, but that is a
larger & riskier set of changes.
Reproducer:
- ifconfig eth0 down
- prepare a DHCPv4 connection with ipv6.method=ignore
- set /proc/sys/net/ipv6/conf/all/dad_transmits to "15"
- ensure that DHCPv4 will fail (replace dhclient with a script
that exits after 2 seconds or something)
- run NetworkManager
- activate the DHCP connection and watch it immediately fail
- wait for the kernel to announce the IPv6LL address after DAD finishes
- watch NM "assume" the new IPv6LL connection
https://bugzilla.gnome.org/show_bug.cgi?id=740096
For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which
caused the DHCP client to exit early because it had no local address
to bind to.
https://bugzilla.gnome.org/show_bug.cgi?id=740147
