Re: [PATCH] dns: store priv->last_iface even when no actual updates are performed

[Dan Williams <dcbw redhat com>]

On Tue, 2013-02-05 at 23:00 +0100, Michael Stapelberg wrote:
> Hi Dan,
> 
> Dan Williams <dcbw redhat com> writes:
> > Sending the interface name is a hack anyway just to make netconfig and
> > resolvconf happy, even though prioritizing DNS information based on
> > interface name is bogus.  NM merges and prioritizes the DNS
> > configuration before sending to resolvconf/netconfig, so whatever
> > interface we happen to send to them is already quite wrong, since the
> > data may come from multiple interfaces.
> >
> > Instead, we should rip out all the interface name stuff and simply send
> > "NetworkManager".  Then people can do whatever they want with NM's data
> > in the resolvconf priority, and I have no idea what netconfig does with
> > INTERFACE=xxx but it's still going to be wrong, whatever it is.
> >
> > (you simply can't prioritize DNS data based on interface names, because
> > interfaces service many different networks.  Sometimes your eth0 is
> > connected to a lower-priority network than your wlan0, sometimes it's
> > higher.  That is a *per-network* decision, not a per-interface one, but
> > netconfig/resolvconf still seem to think it's per-interface...)
> This might be correct for the case you have in mind.
> 
> However, note that I was talking about interface-specific nameserver
> addresses (link-local IPv6), e.g. fe80::4e60:deff:fed8:d7c5%wlan0. Since
> it is that code path in which the segfault is triggered, we clearly need
> to send the _correct_ interface, not just âNetworkManagerâ, otherwise we
> will end up with server=fe80::4e60:deff:fed8:d7c5%NetworkManager in the
> dnsmasq config :-).

Yes, though the solution there is to attach the interface name to the
NMIP4Config and NMIP6Config objects so we can regenerate the right DNS
information no matter when we're asked to update it, since some parts of
it are not interface specific (eg, hostname, as you've found).

So I'll propose a different solution:  check the last patch in the
dcbw/dns-iface git branch, and let me know if that works for you?

http://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=dcbw/dns-iface

Dan