GNOME Bugzilla – Bug 774885
dns=dnsmasq + PEERDNS=no -> dnsmasq not started
Last modified: 2020-11-12 14:33:45 UTC
I wanted to set up caching DNS with dnsmasq and provide it with my own DNS servers settings, ignoring the DNS server from DHCP. To that end, I made the following changes: 1 - Set dns=dnsmasq in NetworkManager.conf 2 - Set up caching /etc/NetworkManager/dnsmasq.d$ cat cache.conf cache-size=1000 3 - Added Google's DNS to dnsmasq: /etc/NetworkManager/dnsmasq.d$ cat gdns.conf server=8.8.8.8 server=8.8.4.4 4 - Used NetworkManager GUI to set my Ethernet's IPv4 to "DHCP, address only" My expectation: /etc/resolv.conf pointing to dnsmasq, which in turn would use Google's DNS servers. What actually happened after a system reboot: 1 - dnsmasq would *not* be started 2 - the "real" resolv.conf (the one that the symlink in /etc points to) would not be created Doing "sudo systemctl stop NetworkManager" and then "sudo systemctl start NetworkManager" would fix both issues, dnsmasq would be started and the real resolve.conf would be created. For now I'm able to work around by changing the connection back to "DHCP (with DNS)" and adding a "supersede domain-name-servers 8.8.4.4" in dhclient.conf. Then dnsmasq is started and the real resolv.conf is created. But it would be nice if the workaround was not necessary. The issue is present on Xubuntu 16.10 and Fedora 24 (XFCE on both) consistent over several reboots. Xubuntu NetworkManager: 1.2.4-0ubuntu1 Fedora NetworkManager: can't say right now, feel free to ask and I'll look it up.
please enable debug logging for NetworkManager, reproduce the problem, and provide a logfile to see what happens. See https://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/contrib/fedora/rpm/NetworkManager.conf?id=c90ec2d8c8a12b44c908bf7f80b23059c29f68fa Thanks.
Please see attachments. NetworkManager logging was set to DEBUG # 1 - nm-start-ubuntu.log 1 - System boot. 2 - journalctl -u NetworkManager -b # 2 - nm-start-restart-ubuntu.log 3 - systemctl restart NetworkManager 4 - journalctl -u NetworkManager -b dnsmasq is now started, Issue 1 (this bug report): dnsmasq not started, DNS not available at all. Issue 2 (new, just noticed): after a "restart, dnsmasq gets the DNS server from my ethernet connection's DHCP, despite "ipv4.ignore-auto-dns" in the connection's config file (created by NetworkManager GUI). Issue 3 (this bug report): why does a "restart NetworkManager" once the system is booted behave differently (start dnsmasq, does not ignore-auto-dns) than a cold start (does not start dnsmasq, ignore-auto-dns is observed)?
Created attachment 340642 [details] nm-start-ubuntu.log system boot and then: journalctl -b --unit NetworkManager
Created attachment 340643 [details] nm-start-restart-ubuntu.log system boot then: systemctl restart NetworkManager then: journalctl -b --unit NetworkManager
Here is another one. After restarting NetworkManager, its GUI tool has two entries under different names for my Ethernet connection (attached). There is only one real device: $ ifconfig enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.22 netmask 255.255.255.0 broadcast 192.168.1.255 Deleting one or the other and then doing a "systemctl restart NetworkManager" ends up with two connections again.
Created attachment 340644 [details] nm-ubuntu-duplicate-connection.png
Hello! Anything?
when NM starts the first time, the log is full of: dns-mgr: (device_ip4_config_changed): queueing DNS updates (1) dns-mgr: (device_ip4_config_changed): DNS configuration did not change dns-mgr: (device_ip4_config_changed): no DNS changes to commit (0) which leads NM to think there is nothing to do and consequently doesn't start dnsmasq. That is a bug. Usually the bug isn't encountered, because there is a DNS configuration around to configure -- or, if there isn't, it doesn't usually matter that NM wouldn't start dnsmasq because it anyway wouldn't resolve any names. (of course, in your scenario it makes a different). >>>>>>>>>>>>>>>>> What happens next on restart is... When you stop NM, it leaves your configuration up (un purpose). After starting NM again, it sees that there is already the device with some IP configuration and it thinks it should preserve that configuration. Thus is generates a new in-memory connection and pretends that connection to be active. That should be fixed by bug 746440. Restarting NetworkManager is seldomly the right thing to do (but of course should work better than it currently does). After restart, NM doesn't have your device in the proper state either, due to bug 746440. You only get it in the right state after you re-activate your connection as a last step via nmcli connection up "Wired Connection 1" Also note, that `ifconfig` shows you your actual networking interfaces. On the other hand, in the sceenshot in nm-connection-editor you see "connection profiles". Of course you can have multiple profiles for one device. In your case, the "enp0s31f6" connection is generated due to the restart. Activating the other connection will remove this connection again. <<<<<<<<<<<<<<<< Anyway, the real bug here is "no DNS changes to commit (0)". How about you work around that by manually configuring 8.8.8.4 as ipv4.dns for your connection? Thanks for the logfiles...
Thank you. Regarding DNS / dnsmasq -- I guess another way to look at it is: Network Manager doesn't see *any* dns servers because I've defined them in dnsmasq config and nowhere else. And it won't read dnsmasq config files because it doesn't know it'll need to start dnsmasq: chicken and egg. And then it's not realistic to expect Network Manager to parse dnsmasq config files as well as dnsmasq itself is able to do -- unless there is some way for NM to ask dnsmasq do that, some sort of "dnsmasq check config, are there any DNS servers defined". --- Yes, setting the connection in NM applet to "DHCP (address only)" and providing DNS servers there worked beautifully -- on Fedora, with NM 1.4.2-f25. On Ubuntu 16.10 I ended up uninstalling Network Manager, think there is a bunch of Ubuntu specific issues not necessarily caused by NM itself and possibly new with 16.10. Thanks again.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).