Bug 1367772

Created attachment 1191625 [details]
dnsmasq system logs

Looking at logs, NetworkManager correctly adds the nameservers to
dnsmasq after the VPN connection is re-established, but it seems
dnsmasq isn't using those server. I think that dnsmasq doesn't handle
properly the destruction and re-creation of the VPN tun interface when
the servers have a "@ifname" suffix.

The dnsmasq issue can be reproduced in the following way:

 * start 'dnsmasq -i'
 * set upstream server specifying the egress interface:

   busctl call uk.org.thekelleys.dnsmasq /uk/org/thekelleys/dnsmasq uk.org.thekelleys.dnsmasq SetServersEx aas 1 1  "192.168.1.1@ens3"

 * check that name resolution works
 * destroy the ens3 interface (for example unloading the NIC module)
 * recreate and configure the interface
 * clear and re-add the nameserver:

   busctl call uk.org.thekelleys.dnsmasq /uk/org/thekelleys/dnsmasq uk.org.thekelleys.dnsmasq SetServersEx aas 0
   busctl call uk.org.thekelleys.dnsmasq /uk/org/thekelleys/dnsmasq uk.org.thekelleys.dnsmasq SetServersEx aas 1 1  "192.168.1.1@ens3"

 * check that name resolution works: this fails

I suspect that the problem lies in the caching of sockets bound to
interfaces inside dnsmasq. From the code it seems that the socket
bound to ens3 is cached and reused later, when the interface is a
different one (albeit with the same name).

I'm reassigning this for analysis to dnsmasq component. Also,
bumping priority as this affects every reconnection to VPNs from
NetworkManager.

Upstream fix:

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b

(In reply to Beniamino Galvani from comment #9)
> Upstream fix:
> 
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;
> h=2675f2061525bc954be14988d64384b74aa7bf8b

I can confirm that this patch fixes the issue for me.

Created attachment 1198427 [details]
upstream patch adapted to rhel 7.3 code base

Could we get Fedora 24 packages respun to give it some testing in the Fedora land, for bug 1373485?

(In reply to Pavel Šimerda (pavlix) from comment #22)
> Created attachment 1198427 [details]
> upstream patch adapted to rhel 7.3 code base

The backport looks ok to me. I noticed there is a follow-up patch to fix a potential crash and that should be backported too:

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=16800ea072dd0cdf14d951c4bb8d2808b3dfe53d

(In reply to Beniamino Galvani from comment #3)
> The dnsmasq issue can be reproduced in the following way:
> 
>  * start 'dnsmasq -i'

Note for QE: there is a typo, this should be 'dnsmasq -1' (to enable dnsmasq to accept updates through D-Bus).

Instead of using D-Bus to perform the updates it's possible to supply the --servers-file= option to specify a configuration file and use SIGHUP to tell dnsmasq to reload it.

The test passes when the last 'reconfigure_downstream_server' is
removed only because doing so removes the CleanCache call and the last
result is returned from the cache.

Comparing version 2.66 with upstream, there is a difference in how new
servers added from D-Bus are handled. They both try to recycle and old
entry in add_update_server() but upstream version always memset()s the
recycled entry (thus clearing the sfd), while 2.66 only overwrites
some fields. This is buggy, as the values in the old server can be
totally unrelated to the new server.

I think we only need to ensure that the sfd (and other fields) are
cleared when we add the new server, instead of reusing possibly bogus
values:

--- a/src/dbus.c
+++ b/src/dbus.c
@@ -161,6 +161,10 @@ static void add_update_server(union mysockaddr *addr,

   if (serv)
     {
+      serv->sfd = NULL;
+      serv->queries = 0;
+      serv->failed_queries = 0;
+
       if (interface)
        strcpy(serv->interface, interface);
       else

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2421.html