Created attachment 368018 [details] emerge --info with USE=resolvconf nm should leave /etc/resolv.conf alone and let resolvconf manage local resolver config. What is does, it WILL indeed give received DND servers to resolvconf, but then overwrites /etc/resolv.conf again which makes usage of resolconf tool clueless. My setup: - local unbound server resolvconf config: resolv_conf=/etc/resolv.conf # If you run a local name server, you should uncomment the below line and # configure your subscribers configuration files below. name_servers="127.0.0.1" unbound_conf=/etc/unbound-resolvconf.conf What I see is: NM activates a connection, then makes resolvconf write /etc/resolv.conf and /etc/unbound-resolvconf.conf with the correct information so we can be sure that nm calls resolvconf correctly, but then nm overwrites /etc/resolv.conf again, so local unbound with the forwarder provided by DHCP used by unbound will never be used.
Please post "emerge -Opv networkmanager" and the contents of /etc/NetworkManager/NetworkManager.conf
(In reply to Pacho Ramos from comment #1) > Please post "emerge -Opv networkmanager" and the contents of > /etc/NetworkManager/NetworkManager.conf [ebuild R ] net-misc/networkmanager-0.9.8.8 USE="bluetooth consolekit dhcpcd introspection modemmanager nss ppp resolvconf wext wifi -avahi -connection-sharing -dhclient -gnutls -systemd {-test} -vala" 0 kB ~ $ cat /etc/NetworkManager/NetworkManager.conf [main] plugins=ifnet,keyfile [ifnet] managed=true auto_refresh=false
Maybe this is caused by ifnet plugin, you could test with "keyfile" *alone* (if you have both listed it will use ifnet by default), but you will need to reconfigure your networks (then, you will need to have your wlan keys near ;))
Removing the ifnet plugin and restarting nm I can connect to my wired network, and /etc/resolv.conf still gets overwritten.
Did you verify it was running keyfile instead of ifnet? (probably it's shown in the logs when restarting) To ensure you use keyfile you can temporally move the NetworkManager.conf to other place If you are using keyfile and still failing, I would report to upstream -> bugzilla.gnome.org
(In reply to Pacho Ramos from comment #5) > Did you verify it was running keyfile instead of ifnet? (probably it's shown > in the logs when restarting) To ensure you use keyfile you can temporally > move the NetworkManager.conf to other place I was pretty sure yes. And I now tried again and moved conf out of the way as you suggested. Jan 20 11:57:56 bart NetworkManager[18726]: Error parsing file '/etc/NetworkManager/NetworkManager.conf': No such file or directory Jan 20 11:57:56 bart NetworkManager[18726]: <info> Loaded plugin keyfile: (c) 2007 - 2010 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. Jan 20 11:57:56 bart NetworkManager[18726]: Error parsing file '/etc/NetworkManager/NetworkManager.conf': No such file or directory Jan 20 11:57:56 bart NetworkManager[18726]: keyfile: parsing Hohaus1 ... Jan 20 11:57:56 bart NetworkManager[18726]: keyfile: read connection 'Hohaus1' [...] And now it works as expected. It also works when just removing the "ifnet" from the plugin list, BUT you have to restart NM 2-3 times until it will work then which is a bit strange. So now we know that this is most propably a bug in the ifnet plugin, right? BTW: My stored (wifi)-connections are still there when it is using keyfile... how can that be? Is must be that although using the ifnet plugin, everythign is also stored in the keyfile as well. But this is what I would expect because I had both plugins loaded (as the expample conf on the ifnet wegpage says) like "plugins=ifnet,keyfile" -Marc
The problem is that I am unsure if we will be able to fix it in ifnet plugin (I think currently nobody is taking care of it :( )
+*networkmanager-0.9.10.0-r1 (13 Oct 2014) + + 13 Oct 2014; Pacho Ramos <pacho@gentoo.org> + +files/networkmanager-0.9.10.0-arpingpath.patch, + +networkmanager-0.9.10.0-r1.ebuild: + Ifnet plugin is now disabled because of it being unattended and unmaintained + for a long time, leading to some unfixed bugs and new problems appearing + (#443596, #458274, #493370, #498372, #523700). If some day somebody volunteers + for fixing/maintaining that plugin and forwarding all that fixes to upstream + it could be re-enabled of course. Append configure option regarding systemd + unit files install path only when systemd support is enabled to prevent + HAVE_SYSTEMD to be true (#524534 by Konstantin Ivanov). Ensure arping is found + (#523632 by Kobboi). +
