The 'device-added' and 'device-removed' signals indicate when the
value of the 'Devices' property changes. The property only returns
realized devices and so if a device unrealizes we should emit the
removed signal for it.
Fixes: 5da37a129chttps://bugzilla.gnome.org/show_bug.cgi?id=771324
(cherry picked from commit cdedd2b53e)
Before switching to gdbus (before 1.2.0), NetworkManager used dbus-glib.
Most objects in the D-Bus API with properties had a signal
NetworkManager-specific "PropertiesChanged" signal. Nowadays, this way of
handling of property changes is deprecated for the common "PropertiesChanged"
signal on the "org.freedesktop.DBus.Properties" interface.
There were a few pecularities in 1.0.0 and earlier:
(1) Due to the implementation with dbus-glib, a property-changed
signal was emitted on *all* interfaces. For example:
- a change on a NMDeviceVeth of "NMDeviceEthernet.HwAddress" would be
emitted both for the interfaces "fdo.NM.Device.Ethernet" and
"fdo.NM.Device.Veth". Note that NMDeviceVeth is derived from
NMDeviceEthernet and there is no "HwAddress" on veth device.
- a change of "NMVpnConnection.VpnState" was emitted on both
interfaces "fdo.NM.VPN.Connection" and "fdo.NM.Connecion.Active".
Note that NMActiveConnection is the parent type of NMVpnConnection and
only the latter has a property "VpnState".
(2) NMDevice's "fdo.NM.Device" interface doesn't have a "PropertiesChanged"
signal. From (1) follows that all property-changes for this type were instead
invoked with an interface like "fdo.NM.Device.Ethernet" (or multiple
interfaces in case of NMDeviceVeth).
1.2.0 introduced gdbus, which gives us the standard "fdo.DBus.Properties"
signal. However, it made the mistake of not realizing (1), thus instead
of emitting the signal once for each interface, it would pick the first
one in the inheritance tree.
With 1.4.0, a bug from merge commit 844345e caused signals for devices
to be only emitted for the interface "fdo.NM.Device.Statistics", instead
of "fdo.NM.Device.Ethernet" or "fdo.NM.Device.Veth" (or both).
The latter is what bgo#770629 is about and what commit 82e9439 tried to fix.
However, the fix was wrong because it tried to do the theoretically correct
thing of emitting the property-changed signal exactly once for the
interface that actually ontains the property. In addition, it missed that
NMDevice doesn't have a PropertiesChanged signal, which caused signals for
"fdo.NM.Device" to get lost *sigh*.
Now, restore the (broken) behavior of 1.0.0. These old-style property changed
signals are anyway considered deprecated and exist solely to satisfy old clients
and preserve the old API.
Fixes: 63fbfad3705db5901e6a2a6a2fc332da0f0ae4be
https://bugzilla.gnome.org/show_bug.cgi?id=770629https://bugzilla.redhat.com/show_bug.cgi?id=1371920
(cherry picked from commit bef26a2e69)
(cherry picked from commit c29ca9b876)
nm_exported_object_notify() hooks GObject's property-change signal
and searches for the D-Bus interface to which to send the
PropertiesChanged signal.
Then it would enqueue the value encoded as GVariant in pending_notifications.
However, thereby the association between the property that changed and the
interface was lost. So later in idle_emit_properties_changed() it would
just pick the first interface with a properties-changed-id.
That is wrong. pending_notifications must be associated with the D-Bus
interface that we are going to notify. That is, each InterfaceData must
have its own separate list.
This is broken since introducing NMExportedObject and moving to gdbus.
Only now it was discovered as NMDevice itself has two D-Bus interfaces:
"Device" and "Device.Statistics".
Note that the order of the PropertiesChanged in our D-Bus API is not defined
so that later signals can reach the receiver before earlier signals.
Also, multiple change signals for one property may be combined.
That is not changed by this patch and is not considered a bug, but something
that our D-Bus API wrt. PropertiesChanged does not guarantee.
https://bugzilla.gnome.org/show_bug.cgi?id=770629
(cherry picked from commit 82e94390de)
(cherry picked from commit 8d9ea18b3d)
We might be already handling a state change:
Aug 17 05:26:34 dacan.local NetworkManager[618]: (devices/nm-device.c:10982):
_set_state_full: runtime check failed: (priv->in_state_changed == FALSE)
(gdb) bt
#0 0x00007fc218dad643 in g_logv (log_domain=0x7fc21c0db3c3 "NetworkManager", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7ffe6f0b30d0) at gmessages.c:1086
#1 0x00007fc218dad7bf in g_log (log_domain=log_domain@entry=0x7fc21c0db3c3 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x7fc218e1b70f "%s") at gmessages.c:1119
#2 0x00007fc218dadb16 in g_warn_message (domain=domain@entry=0x7fc21c0db3c3 "NetworkManager", file=file@entry=0x7fc21c0d6597 "devices/nm-device.c", line=line@entry=10982, func=func@entry=0x7fc21c0dabf0 <__FUNCTION__.42233> "_set_state_full", warnexpr=warnexpr@entry=0x7fc21c0d95a0 "priv->in_state_changed == FALSE") at gmessages.c:1152
#3 0x00007fc21bf79bd6 in _set_state_full (self=0x7fc21ccd88b0 [NMDeviceEthernet], state=NM_DEVICE_STATE_FAILED, reason=NM_DEVICE_STATE_REASON_DEPENDENCY_FAILED, quitting=0) at devices/nm-device.c:10982
#7 0x00007fc2190bdd9f in <emit signal notify:master on instance 0x7fc21ccd88b0 [NMDeviceEthernet]> (instance=instance@entry=0x7fc21ccd88b0, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3439
#4 0x00007fc2190a3908 in g_closure_invoke (closure=0x7fc21cd009e0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7ffe6f0b34b0, invocation_hint=invocation_hint@entry=0x7ffe6f0b3450) at gclosure.c:801
#5 0x00007fc2190b5a1d in signal_emit_unlocked_R (node=node@entry=0x7fc21cb66500, detail=detail@entry=588, instance=instance@entry=0x7fc21ccd88b0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffe6f0b34b0)
at gsignal.c:3627
#6 0x00007fc2190bdab1 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ffe6f0b3640) at gsignal.c:3383
#8 0x00007fc2190a7fd4 in g_object_dispatch_properties_changed (object=0x7fc21ccd88b0 [NMDeviceEthernet], n_pspecs=<optimized out>, pspecs=<optimized out>) at gobject.c:1061
#9 0x00007fc2190aa619 in g_object_notify_by_pspec (pspec=<optimized out>, object=0x7fc21ccd88b0 [NMDeviceEthernet]) at gobject.c:1155
#10 0x00007fc2190aa619 in g_object_notify_by_pspec (object=object@entry=0x7fc21ccd88b0 [NMDeviceEthernet], pspec=<optimized out>) at gobject.c:1264
#11 0x00007fc21bf7de3f in nm_device_master_enslave_slave (prop=PROP_MASTER, obj=0x7fc21ccd88b0 [NMDeviceEthernet]) at devices/nm-device.c:103
#12 0x00007fc21bf7de3f in nm_device_master_enslave_slave (success=1, self=0x7fc21ccd88b0 [NMDeviceEthernet]) at devices/nm-device.c:2757
#13 0x00007fc21bf7de3f in nm_device_master_enslave_slave (self=0x7fc21cd42810 [NMDeviceBond], slave=0x7fc21ccd88b0 [NMDeviceEthernet], connection=<optimized out>) at devices/nm-device.c:1300
#14 0x00007fc2167c8dcc in ffi_call_unix64 () at ../src/x86/unix64.S:76
#15 0x00007fc2167c86f5 in ffi_call (cif=cif@entry=0x7ffe6f0b3a10, fn=<optimized out>, rvalue=0x7ffe6f0b3980, avalue=avalue@entry=0x7ffe6f0b3900) at ../src/x86/ffi64.c:522
#20 0x00007fc2190be2e8 in <emit signal 0x7fc21c0ea3d5 "state-changed" on instance 0x7fc21ccd88b0 [NMDeviceEthernet]> (instance=instance@entry=0x7fc21ccd88b0, detailed_signal=detailed_signal@entry=0x7fc21c0ea3d5 "state-changed") at gsignal.c:3479
#16 0x00007fc2190a4148 in g_cclosure_marshal_generic (closure=0x7fc21cc84de0, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1487
#17 0x00007fc2190a3908 in g_closure_invoke (closure=0x7fc21cc84de0, return_value=return_value@entry=0x0, n_param_values=4, param_values=param_values@entry=0x7ffe6f0b3c10, invocation_hint=invocation_hint@entry=0x7ffe6f0b3bb0) at gclosure.c:801
#18 0x00007fc2190b5a1d in signal_emit_unlocked_R (node=node@entry=0x7fc21cbeef20, detail=detail@entry=0, instance=instance@entry=0x7fc21ccd88b0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffe6f0b3c10) at gsignal.c:3627
#19 0x00007fc2190bdab1 in g_signal_emit_valist (instance=instance@entry=0x7fc21ccd88b0, signal_id=signal_id@entry=112, detail=detail@entry=0, var_args=var_args@entry=0x7ffe6f0b3e48) at gsignal.c:3383
#21 0x00007fc21bf79e3d in _set_state_full (self=self@entry=0x7fc21ccd88b0 [NMDeviceEthernet], state=state@entry=NM_DEVICE_STATE_IP_CONFIG, reason=reason@entry=NM_DEVICE_STATE_REASON_NONE, quitting=quitting@entry=0) at devices/nm-device.c:11123
#22 0x00007fc21bf7a707 in nm_device_state_changed (self=self@entry=0x7fc21ccd88b0 [NMDeviceEthernet], state=state@entry=NM_DEVICE_STATE_IP_CONFIG, reason=reason@entry=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:11308
#23 0x00007fc21bf7e92f in activate_stage3_ip_config_start (self=0x7fc21ccd88b0 [NMDeviceEthernet]) at devices/nm-device.c:6759
#24 0x00007fc21bf68dac in activation_source_handle_cb (self=0x7fc21ccd88b0 [NMDeviceEthernet], family=family@entry=2) at devices/nm-device.c:3627
#25 0x00007fc21bf68e6e in activation_source_handle_cb4 (user_data=<optimized out>) at devices/nm-device.c:3564
#26 0x00007fc218da6d7a in g_main_context_dispatch (context=0x7fc21cb6e000) at gmain.c:3152
#27 0x00007fc218da6d7a in g_main_context_dispatch (context=context@entry=0x7fc21cb6e000) at gmain.c:3767
#28 0x00007fc218da70b8 in g_main_context_iterate (context=0x7fc21cb6e000, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3838
#29 0x00007fc218da738a in g_main_loop_run (loop=0x7fc21cb6c8c0) at gmain.c:4032
#30 0x00007fc21bf4a23e in main (argc=1, argv=0x7ffe6f0b43e8) at main.c:411
(gdb)
https://bugzilla.redhat.com/show_bug.cgi?id=1367702
(cherry picked from commit d070d7f47d)
Fix the following build error:
nm-auth-utils.c: In function ‘nm_auth_chain_add_call’:
nm-auth-utils.c:402:46: error: ‘DBUS_GERROR’ undeclared (first use in this function)
call->chain->error = g_error_new_literal (DBUS_GERROR,
Fixes: 1cf35cb26b
(cherry picked from commit b9e89c918f)
It's possible for wpa_supplicant to transition to INACTIVE
state with an outstanding requested_scan pending. This can
lead to a stall condition where scanning no longer occurs.
[thaller@redhat.com: added break statement to avoid fall-through]
https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00116.html
(cherry picked from commit eed8fd2e43)
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)
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)
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)
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)
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)
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
(cherry picked from commit 3f8a60def6)
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.
(cherry picked from commit 18501d7b68)
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).
(cherry picked from commit 5357b1874e)
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
(cherry picked from commit 51791c4772)
Currently we don't specify to dnsmasq which interface must be used to
contact a given nameserver and so requests can be sent through the
wrong interface.
Fix this by concatenating a @interface prefix to each server (unless
an IPv6 interface scope-id is already present).
https://bugzilla.gnome.org/show_bug.cgi?id=765153
(cherry picked from commit b71e104d33)
