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 _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
