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().
This will replace nm_connection_provider_get_connections(), but has
a different API.
Instead of returning a (const) GSList list, it returns a (cached) NULL
terminated array. The reason for this change is simply that I find
arrays more convenient to use (in this case) and it doesn't have the
overhead of a GSList instance per entry.
Like with nm_connection_provider_get_connections(), cache the result
internally. This for one is more convenient for the caller, which
doesn't need to free the result. On the other hand, the list of
connections is fairly static, this allows us to reuse the same list.
nm_settings_get_connections() returns a sorted list. We have many users
of nm_connection_provider_get_connection(), which returns the same result,
but undefined order.
Next NMConnectionProvider will be dropped. Thus, we don't want to
seamlessly replace nm_connection_provider_get_connection() by a sorted
version nm_settings_get_connections().
Rename nm_settings_get_connections() to make clear it is sorted.
Downstream might want to choose a different default value for
main.rc-manager setting (and it can does so, by compiling with
explicit resolvconf or netconfig support).
Make the default configurable at build-time and also embed it into
the manual page of "NetworkManager.conf".
https://bugzilla.redhat.com/show_bug.cgi?id=1337222
