rpmdiff complains:
Subpackage NetworkManager-bluetooth on aarch64 x86_64 ppc64 ppc64le s390x
consumes library libnm-wwan.so()(64bit) from subpackage NetworkManager-wwan
but does not have explicit package version requirement.
Please add Requires: NetworkManager-wwan = %{version}-%{release} to
NetworkManager-bluetooth in the specfile to avoid the need to test
interoperability between the various combinations of old and new subpackages.
And indeed, device plugins don't have a stable API/ABI, and requires
exact NetworkManager and wwan versions. This was already enforced implicitly,
because all device plugins require the same exact NetworkManager version.
Shared headers are all project-wide and internal API.
Currently we have the following:
General purpose:
- shared/gsystem-local-alloc.h: header-only, allocation macros
- shared/nm-dbus-compat.h: header-only, D-Bus related defines
- shared/nm-glib.h: header-only, glib compatibility defines
- shared/nm-macros-internal.h: header-only, utils
- shared/nm-shared-utils.[hc]: source and header, utils
- shared/nm-test*.[hc]: source and header, libnm testing utils
Special to NetworkManager repository:
- shared/nm-version-macros.h.in: header-only, version macros
- shared/nm-default.h: header-only, default-include
Now we add "shared/nm-common-macros.h" which is header-only, but non
general purpose.
I am running low on good names, considering all the shared/core/macros
utils headers. Still, I think "nm-common-macros.h" is appropriate.
The [.config] section is configuration about the configuration file itself,
it should not be merged.
Properly ignore the [.config] section before merging the configuration
file.
Support 3 new flags for Reload:
- 0x01 (CONF): reload the configuration from disk
- 0x02 (DNS_RC): write DNS configuration to resolv.conf
- 0x04 (DNS_FULL): restart DNS plugin
Omitting all flags is the same as reloading everything, thus SIGHUP.
Add new Reload D-Bus command to reload NetworkManager configuration.
For now, this is like sending SIGHUP to the process. There are several
advantages here:
- it is guarded via PolicyKit authentication while signals
can only be sent by root.
- the user can wait for the reload to be complete instead of sending
an asynchronous signal. For now, we operation completes after
nm_config_reload() returns, but later we could delay the response
further until specific parts are fully reloaded.
- SIGHUP reloads everything including re-reading configuration from
disk while SIGUSR1 reloads just certain parts such as writing out DNS
configuration anew.
Now, the Reload command has a flags argument which is more granular
in selecting parts which are to be reloaded. For example, via
signals the user can:
1) send SIGUSR1: this writes out the DNS configuration to
resolv.conf and possibly reloads other parts without
re-reading configuration and without restarting the DNS plugin.
2) send SIGHUP: this reloads configuration from disk,
writes out resolv.conf and restarts the DNS plugin.
There is no way, to only restart the DNS plugin without also reloading
everything else.
For the most part, this patch just renames some change-flags, but
doesn't change much about them. The new name should better express
what they are.
A config-change signal can be emitted for different reasons:
when we receive a signal (SIGHUP, SIGUSR1, SIGUSR2) or for internal
reasons like resetting of no-auto-default or setting internal
values.
Depending on the reason, we want to perform different actions.
For example:
- we reload the configuration from disk on SIGHUP, but not for
SIGUSR1.
- For SIGUSR1 and SIGHUP, we want to update-dns, but not for SIGUSR2.
Another part of the change-flags encodes which part of the configuration
actually changed. Often, these parts can only change when re-reading
from disk (e.g. a SIGUSR1 will not change any configuration inside
NMConfig).
Later, we will have more causes, and accordingly more fine-grained
effects of what should be done on reload.
Previously, on SIGHUP we would re-read the configuration and possibly
reconfigure DNS. However, if the DNS plugin didn't change, we would
not restart it. That is good, because restarting the DNS plugin shortly
interrupts name resolution.
dnsmasq might depend on additional configuration from /etc/NetworkManager/dnsmasq.d,
thus, the user also needs a way to restart the plugin to pickup the
configuration. For that, it could just kill the dnsmasq instance, but
that means, ratelimiting will hit and restarting dnsmasq too often
might bork the plugin for 5 minutes.
Now, on SIGHUP, also restart the DNS plugin. The advantage is that
one signal reloads everything, including the dnsmasq instance, without
ratelimiting.
The disadvantage is, that it shortly interrupts name resolution.
This also fixes cancelling the timeout in dispose().
Just to be explicit, also cancel it in dispose(),
although dispose() alreay calls _clear_plugin().
_clear_plugin() should explicitly stop the DNS plugin, instead of just
unreferencing it. Unreferencing does not necessarily mean, that the
plugin will be destroyed right away.
Otherwise, when killing dnsmasq it does not get respawned:
dnsmasq[0x560dd7e43cf0]: dnsmasq exited normally
dns-mgr: plugin dnsmasq child quit unexpectedly
dns-mgr: update-dns: updating resolv.conf
dns-mgr: config: 100 best v4 enp0s25
dns-mgr: config: 100 best v6 enp0s25
dns-mgr: config: 100 default v6 lo
dns-mgr: config: 100 default v4 lo
dns-mgr: update-dns: updating plugin dnsmasq
dnsmasq[0x560dd7e43cf0]: adding nameserver '192.168.0.2@enp0s25'
dnsmasq[0x560dd7e43cf0]: trying to update dnsmasq nameservers
dns-mgr: update-resolv-conf: write internal file /var/run/NetworkManager/resolv.conf succeeded but don't update /etc/resolv.conf as it points to resolv.conf.nm
dnsmasq[0x560dd7e43cf0]: dnsmasq disappeared
Previously, we would create priv->dnsmasq proxy only once,
and not respawn the process at all.
https://bugzilla.gnome.org/show_bug.cgi?id=766996
When the ipv4.dhcp-fqdn property is set, NM adds the following options
to dhclient.conf:
send fqdn.fqdn "foo.bar";
send fqdn.encoded on;
send fqdn.server-update on;
which enable the S (server-update) and E (encoded) flags in DHCP
option 81, since they are sensible default values and dhclient
requires a "send fqdn.server-update [on|off]" directive in order to
send the option.
Users may want to change these flags according to their server's
configuration, but this is not possible at the moment since NM options
are placed after user's ones, overriding them.
To fix this, collect user's fqdn options and add them after NM
configuration; note that the fqdn.fqdn option still can't be
overridden by users, as NM must control the FQDN sent to server.
Fixes: c3573ebf2b
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
