When trying to add new slaves to a bond connection, for the first
slave nmt_add_connection_show() is called with !priv->single_type to
display a slave-type selection form. For the second slave the type is
predefined and thus nmt_add_connection_show() doesn't show the dialog;
instead it calls create_connection() directly, which invokes
nmt_newt_form_quit() on the not-shown dialog causing:
nmtui-CRITICAL **: nmt_newt_form_quit: assertion 'priv->form != NULL' failed
Don't call nmt_newt_form_quit() if the form was not shown.
https://bugzilla.gnome.org/show_bug.cgi?id=768981
(cherry picked from commit 2eafd0ea52)
Not default when linking with GOLD linker, but used for loading the VPN
plugins. We still get it when using NSS by dumb luck, but GnuTLS doesn't
drag it in.
https://bugzilla.gnome.org/show_bug.cgi?id=769328
(cherry picked from commit b01219ad1b)
Commit f85941ee91 ("device: don't try to generate ipv6ll address for
disconnected devices") disabled the generation of IPv6 link-local
addresses for disconnected devices to fix a crash. However that broke
the following:
$ ip a f dev eth0
$ systemctl start NetworkManager
$ nmcli d
DEVICE TYPE STATE CONNECTION
eth0 ethernet disconnected eth0
$ ip a a dev eth0 2001::42/64
$ ip a show eth0
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:52:00:61:32:81 brd ff:ff:ff:ff:ff:ff
inet6 2001::42/64 scope global
valid_lft forever preferred_lft forever
(no link-local address)
Revert that change.
Fixes: f85941ee91
(cherry picked from commit 75406d1760)
If the device is disconnected because it can't be assumed due to lack
of IP configuration, don't try to generate an ipv6 link-local address,
as this requires a connection.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 __GI_abort () at abort.c:89
#2 g_assertion_message (domain=domain@entry=0x5f41b4 "NetworkManager", file=file@entry=0x5ef9b5 "devices/nm-device.c", line=line@entry=831,
func=func@entry=0x5f3220 <__FUNCTION__.37383> "nm_device_get_ip_iface_identifier", message=message@entry=0x1e86100 "assertion failed: (connection)") at gtestutils.c:2429
#3 g_assertion_message_expr (domain=domain@entry=0x5f41b4 "NetworkManager", file=file@entry=0x5ef9b5 "devices/nm-device.c", line=line@entry=831,
func=func@entry=0x5f3220 <__FUNCTION__.37383> "nm_device_get_ip_iface_identifier", expr=expr@entry=0x5e65c6 "connection") at gtestutils.c:2452
#4 nm_device_get_ip_iface_identifier (self=self@entry=0x1e612a0, iid=iid@entry=0x7fffce40e3d0, ignore_token=ignore_token@entry=1) at devices/nm-device.c:831
#5 check_and_add_ipv6ll_addr (self=self@entry=0x1e612a0) at devices/nm-device.c:5983
#6 queued_ip6_config_change (user_data=0x1e612a0) at devices/nm-device.c:9489
#7 g_main_dispatch (context=0x1d3e060) at gmain.c:3154
#8 g_main_context_dispatch (context=context@entry=0x1d3e060) at gmain.c:3769
#9 g_main_context_iterate (context=0x1d3e060, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840
#10 g_main_loop_run (loop=0x1d3ab00) at gmain.c:4034
#11 main (argc=1, argv=0x7fffce40e6a8) at main.c:411
https://bugzilla.redhat.com/show_bug.cgi?id=1351633
(cherry picked from commit f85941ee91)
Since commit 7d1709d7f6 ("device: check may_fail when progressing to
IP_CHECK") NM correctly checks the may-fail properties to decide
whether a connection must fail after the completion of IP
configuration. But for ipv4.method=disabled and ipv6.method=ignore the
IP configuration is always considered failed and thus setting
may-fail=no results in a connection that can never succeed.
To prevent such wrong configuration, force may-fail to TRUE for those
methods during connection normalization.
https://bugzilla.redhat.com/show_bug.cgi?id=1334884
(cherry picked from commit ac73758305)
Having a gateway defined when never-default=yes causes troubles in
connection matching and anyway makes no sense.
If the combination is found, remove the gateway during the
normalization phase.
https://bugzilla.redhat.com/show_bug.cgi?id=1313091
(cherry picked from commit c1907a218a)
The dhclient and dhcpcd clients can be destroyed during disposal of
the DHCP manager singleton and at that point the NMDhcpListener
singleton can be already gone. Reference it in the clients.
(cherry picked from commit e5430a182c)
On 32-bit architectures long and int have the same size and thus it's
wrong to use nmc_string_to_int() since it uses strtol() and the @max
argument can't represent G_MAXUINT32. Use nmc_string_to_uint()
instead.
https://bugzilla.redhat.com/show_bug.cgi?id=1350201
(cherry picked from commit 938a4b35c6)
DNS properties should not be copied to parent device's configuration
otherwise they will be applied twice, possibly with two different DNS
priorities.
(cherry picked from commit df48628a48)
Previously we created a new NMIP[46]Config object to replace the
previous one every time the plugin reported a new IP configuration
through the Ip[46]Config signal, but the old configuration was not
removed from the DNS manager and would become stale.
The interaction with DNS manager is handled by NMPolicy, which only
reacts to changes in connection status, so it's not easy to have the
configuration removed from DNS while keeping the connection state
ACTIVATED.
A cleaner solutions is to avoid creating a new IP configuration object
and reuse the existing one if possible. The side effect is that the
D-Bus path of the object will not change, which seems also positive.
https://bugzilla.redhat.com/show_bug.cgi?id=1348901
(cherry picked from commit 641e8b00fe)
If the plugin sends a new configuration when the connection is already
activated the state should not go back to PRE_UP since this causes
dispatcher scripts to run again.
(cherry picked from commit 19133b08da)
Software devices must report the NM_DEVICE_CAP_IS_SOFTWARE capability
in order to be properly activated. Add the flag to NMDeviceTun and
NMDeviceVxlan.
https://bugzilla.gnome.org/show_bug.cgi?id=767846
(cherry picked from commit f2d5c8d7f8)
nl_recv() in libnl3 before version 3.2.15 would return dangling pointers
if nl_recv() fails or has nothing to read [1].
Workaround that by explicitly clearing @buf and @creds.
https://bugzilla.gnome.org/show_bug.cgi?id=767986
[1] 69468517d0
(cherry picked from commit 66715515dc)
Backpot a large set of patches from master related to handling DNS.
This includes:
- add support for DNS priorities
- extend rc-manager configuration option with new values
"symlink" and "unmanaged"
- fix rc-manager=file behavior to follow symlinks
- make default rc-manager option configurable at compile time
- fix restarting dnsmasq
- restart DNS plugin on SIGHUP
- add Reload D-Bus call
- support CIDR for reverse DNS entries
When a reverse DNS entry must be added to dnsmasq, instead of
considering IP addresses as classful use the prefix to compute one or
more "in-addr.arpa" according to CIDR rules.
https://bugzilla.gnome.org/show_bug.cgi?id=767174
(cherry picked from commit 4d1e7dc23c)
With
[main]
#dns=
we would see in the log:
dns-mgr: init: dns=(null), rc-manager=symlink
Instead, it should be
dns-mgr: init: dns=default, rc-manager=symlink
Also, we should avoid logging NULL values with "%s", although
glib's printf is fine with that.
(cherry picked from commit bcb88d540e)
Before, we would first check whether the file is immuable before
parsing main.rc-manager setting. That means, if you configured
[main]
dns=default
rc-manager=unmanged
we would still first try to detect whether the file is immutable.
The result of course is only minor, e.g. showing up in logging
as rc-manager=immutable instead of rc-manager=unmanged.
Also, an immutable resolv.conf would suppress a warning about
a bogus rc-manager setting.
Also, when selecting rc-manager=symlink and resolv.conf is a symlink
to an immutable file, we don't actually care about that. The reason is,
that if the link-target is not /var/run/NetworkManager/resolv.conf,
we anyway wouldn't modify the file.
The effect of this change is pretty minor, now in logging you would see:
dns-mgr: init: dns=default, rc-manager=symlink
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 /some/where/else
instead of
dns-mgr: init: dns=default, rc-manager=immutable
dns-mgr: update-resolv-conf: write internal file /var/run/NetworkManager/resolv.conf succeeded
Which feels slightly more right.
Note that symlinks cannot have file attributes.
(cherry picked from commit 4711867915)
Until before 1.2.0, NetworkManager would always write resolv.conf as file, but
if /etc/resolv.conf was a symlink, it would follow the link instead of
replacing it with a file ([1], [2]).
With 1.2.0, we initially dropped that behavior and added a new 'rc-manager=none'
which writes resolv.conf to /var/run/NetworkManager and symlinks resolv.conf [3].
In case resolv.conf being already a symlink to another target, it would
not be replaced [4].
Later, we added 'rc-manager=file', which always writes /etc/resolv.conf as
file [5].
With 1.4.0, we will rename 'rc-manager=none' to 'rc-manager=symlink' [6].
This commit now fixes 'rc-manager=file' to restores the pre-1.2 behavior
and follow symlinks.
[1] 5761e328b8
[2] https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/324233
[3] 4805be2ed2
[4] 583568e12f
[5] 288799713d
[6] cd6a469668https://github.com/NetworkManager/NetworkManager/pull/7
(cherry picked from commit 718fd22436)
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.
(cherry picked from commit ed551a4633)
Also when config_data changes, the logging line should start with
"config: signal" like it does in the other cases.
(cherry picked from commit 02034cead3)
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.
(cherry picked from commit ca5028e608)
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.
(cherry picked from commit 0acee97220)
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.
(cherry picked from commit 1d0e0eeffd)
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.
(cherry picked from commit eb6140a772)
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.
(cherry picked from commit 9ae307347b)
This also fixes cancelling the timeout in dispose().
Just to be explicit, also cancel it in dispose(),
although dispose() alreay calls _clear_plugin().
(cherry picked from commit a920155d0b)
_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.
(cherry picked from commit e1d5b27c4f)
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
(cherry picked from commit 28938155e0)
