NMSettingTeam implements a custom compare_property() method in order
to perform a relaxed matching on team configurations when it is
necessary to assume a connection. However, the method is called also
when the core needs to check if a connection has changed before an
update. In that case it is better to use the default string comparison
on the property, otherwise the second of these commands would not have
effect:
$ nmcli connection modify team0 team.config ''
$ nmcli connection modify team0 team.config '{ }'
because compare_property() returns TRUE. Use the @flags argument to
distinguish the two cases.
Fixes: 82f8a54854
RFC 4704 ("The DHCPv6 Client FQDN Option") allows both partial and
fully-qualified names in the FQDN option, however dhclient always
appends a terminating zero-length label to the name, so we ignore
unqualified hostnames to prevent a wrong configuration.
Emit a warning when the field is ignored so that users can clearly see
why the hostname is not being sent.
For changing the hardware address, we must bring the device down. When doing
that, IP addressing is lost and it must be re-configured after bringing the
device up again.
We already do something similar in device_link_changed(), but that might
not be sufficient, because device_link_changed() is run on an idle
handler, thus, while changing the hardware address it has no chance to
run (or notice that the device was shortly down).
https://bugzilla.redhat.com/show_bug.cgi?id=1309899
We don't need the token set in platform for our address mode generation,
but having it set makes it possible to correctly generate and assume
connections that use tokens.
The only user of platform who accesses this field is NMDevice,
when calling nm_platform_link_get_ipv6_token(). It cares more
about whether the token is all-zero or set to something.
Another use of inet6_token.is_valid was so that when we receive a
netlink message without IFLA_INET6_TOKEN attribute, that we don't
treat the value as zero, although it is just unknown. Fix that
instead in a better way by setting the value from the cache, if
IFLA_AF_SPEC doesn't provide it.
Also, when printing the token in nm_platform_link_to_string()
treat it as an IPv6 address (inet_ntop).
The DNS priority property of a IP configuration determines how the
configuration compares to others when deciding their order, but
doesn't specify directly parameters to be applied. In other words, two
configurations which differs only for the dns-priority should have the
same hash as applying them will give the same result.
Especially, when the DNS manager computes the hash of IP
configurations, the ones without real configuration data (servers,
domans, options...) should not change the hash value.
Thus, exclude the property from the hash computation and dowgrade any
modification to 'minor change'.
Fixes: bfabfb05ae
Fixes: f09f5e1ec8
internal systemd code produces logging messages by itself, like
libsystemd: DHCP CLIENT (0x9204b5ce): ACK
Let's log the pointer value initially, to associate the logged "xid"
with the pointer value of the client.
Now we get:
<trace> [1464520695.7655] dhcp4 (enp0s25): dhcp-client4: set 0x556cdd9d6800
<debug> [1464520695.7658] libsystemd: DHCP CLIENT (0x9d87b7c5): STARTED on ifindex 2
When the list of DNS servers changes, old DNS entries cached by
dnsmasq must be invalidated as the answers returned by new servers may
be different (especially, old NXDOMAIN entries may now be valid). Call
the dnsmasq "ClearCache" D-Bus method to achieve this.
https://bugzilla.redhat.com/show_bug.cgi?id=1338731
nm-libreswan VPN has no own IP interface. Thus we got an
assertion failure in nm_dns_manager_add_ip_config().
Fix that, by using the IP interface of the parent device.
Since 027f4c65ac, the ip_iface for
nm_dns_manager_add_ip_config() must be set.
Wit interface-less VPN types like libreswan, we thus hit the assertion
nm_dns_manager_add_ip_config: assertion 'iface && iface[0]' failed
Fix that, by fallback to the interface name of the parent device.
Fixes: 027f4c65ac
and nm_vpn_connection_get_ip_ifindex(). For VPN types that have no own
IP interface, we often want instead lookup the IP interface from the
parent device.
ip_iface and ip_ifindex come as a pair. They must be either set both, or not
at all. Ensure that whenever setting one, the other is set too (or cleared).
Add a new "Config" property to the D-Bus interface for team devices
and show its value through "nmcli device show". The property contains
the full JSON configuration from teamd for the device.
https://bugzilla.redhat.com/show_bug.cgi?id=1310435
Sometimes the netlink event lacks the IFLA_ADDRESS attribute with
the MAC address of the link. In this case, take the value from
the cached link instance. A missing netlink attribute should have the
meaning of reusing the previous value, not clearing the address.
Introduce two environment variables to configure logging
for the VPN plugins:
- NM_VPN_LOG_LEVEL: when set, a syslog logging level (0-7).
- NM_VPN_LOG_SYSLOG: either 0 or 1, whether the plugin should
log to stdout or syslog. Basically, if NetworkManager itself
runs in the forground, we also want that the plugin logs
to stdout.
This logging domain will be used to enable debugging of the VPN plugins.
However, the plugins might expose sensitive data in this mode, so exclude
the new domain from "LOGD_ALL".
This is not C# but glib. Using interfaces is so cumbersome, that they
don't simplify code but make it more complicated.
E.g. following signals and its subscribers is complicated enough. It gets
more complicated by having NM_SETTINGS_SIGNAL_CONNECTION_ADDED and
NM_CP_SIGNAL_CONNECTION_ADDED. Of course, your favorite IDE has no idea
about glib interfaces, so figuring out who calls who gets more
complicated.
This undoes commit 4fe48b1273. Originally,
NMConnectionProvider had only one function get_best_connection(). But it
kept growing and more functions were added.
If we want to ~hide~ certain part of the NMSettings API, we should move them
to a separate header which gives internal access.
Instead of accessing the singleton getter nm_settings_get(), obtain
the settings instance from the device instance itself via
nm_device_get_settings().
