Re: DNS from wifi not removed when switching to wire after suspend/resume

[Dan Williams <dcbw redhat com>]

On Tue, 2009-11-17 at 22:23 +0000, Frederik Himpe wrote:
> On Tue, 17 Nov 2009 12:55:00 -0800, Dan Williams wrote:
> 
> > On Tue, 2009-11-17 at 08:13 +0000, Frederik Himpe wrote:
> >> I'm using NetworkManager 0.7.996 (git 20091021 snapshot) on Mandriva,
> >> built with dhclient and resolvconf support.
> >> 
> >> I have a wireless connection to my AP at home and a wired DHCP
> >> connection configured in networkmanager, both set to autoconnect and
> >> available to all users. At home, networkmanager connects to my wireless
> >> AP automatically. Then I suspend my system and resume it at work, where
> >> it's docked and has a wired DHCP connection. NetworkManager connects
> >> automatically to the wired connection, and deactivates the wlan0
> >> connection, however NetworkManager just adds the DNS servers from my
> >> wired connection at work to resolv.conf without removing the DNS server
> >> from my wireless home connection. This results in long waits when
> >> resolving hostnames.
> > 
> > Nov 17 08:56:27 defected NetworkManager: <info> (eth0): writing
> > resolv.conf to /sbin/resolvconf
> > 
> > Until we figure out how resolvconf is interacting with NM here, or until
> > we add more debugging to NM to figure out what's going on and what
> > exactly NM is writing to resolvconf (which I'm pretty sure is correct),
> > if you move /sbin/resolvconf out of the way, does allowing NM to write
> > /etc/resolv.conf directly make things work again?
> 
> OK, I will test this tomorrow and I'll let you know.
> 
> Looking at resolvconf's man page, I guess that NetworkManager only calls 
> networkmanager -a, which will add stuff to resolvconf, but does not call 
> resolvconf -d first to clean up the outdated entries.
> 
> This seems to happen in src/named-manager/nm-named-manager.c in 
> dispatch_resolvconf.
> 
> I can indeed reproduce the problem by running resolvconf -a NetworkManager 
> and then sending a new nameserver: it will simply be added to resolv.conf 
> without removing the old one.

Ah, maybe we should call -d unconditionally before calling -a.  That
might explain a few things.

> Actually, I'm surprised to see that NM always calls resolvonf with the 
> name NetworkManager as INTERFACE name. I rather expected it to call it 
> with the UUID or interface name of the connection, so that it simply calls 
> resolvonf -a UUID (or IFNAME) for every connection which comes online, and 
> resolvconf -d UUID/IFNAME for every connection going down. But I guess you 
> don't want this because NM wants to take complete control of resolv.conf 
> instead of letting the contents be managed by resolvconf?

It's mainly to kludge in support for resolvconf; I'm not sure the
original patch had that in it it.  That sounds like a good improvement
though, but we need to figure out a few things first...

Like VPNs.  If I connect wifi (and send those nameservers to resolvconf)
then connect a VPN (and send those), then plug in a wired cable (and
send those), aren't the VPN's nameservers now not used?  NM will ensure
they do get used.

I guess NM would need to ensure that every time DNS got updated, that
re-added the "best" connections' DNS servers unconditionally?

Any chance you'd like to look into a patch for all this too? :)

Dan