GNOME Bugzilla – Bug 778430
The search domain string in resolv.conf is being duplicated leading to problems with DNS
Last modified: 2017-03-03 13:24:31 UTC
Link to a bug report for Debian Testing: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854343 Basically after an update to 1.6.0 the search domain string from the DHCP server is being duplicated - e.g. 'search domain.orgdomain.org' - in resolv.conf which leads to hostnames not being resolved without the full domain name. The only other noteworthy observation is that whenever I connect to a VPN both the local and the remote domain strings are configured correctly. This has been reported by Josh Triplett as well (see original bug report). Let me know what else I could provide to track this down. --Tilo
Can you please attach the lease file generated by dhclient (the argument after "-lf" in "ps ax | grep dhclient" output)? Thanks!
Created attachment 345412 [details] dhclient lease file
(In reply to Tilo Villwock from comment #2) > Created attachment 345412 [details] > dhclient lease file option domain-name "company.localcompany.local"; Since NM uses the value provided by dhclient as is, and I don't see any recent changes in the NM code for option parsing I tend to think the issue is in dhclient. To confirm this, can you please try: systemctl stop NetworkManager dhclient enp3s0 cat /etc/resolv.conf ? If the domain name is populated correctly, let's have a look at the lease file and compare it with the previous one.
(In reply to Beniamino Galvani from comment #3) > (In reply to Tilo Villwock from comment #2) > > Created attachment 345412 [details] > > dhclient lease file > > option domain-name "company.localcompany.local"; > > Since NM uses the value provided by dhclient as is, and I don't see > any recent changes in the NM code for option parsing I tend to think > the issue is in dhclient. > > To confirm this, can you please try: > > systemctl stop NetworkManager > dhclient enp3s0 > cat /etc/resolv.conf > > ? > > If the domain name is populated correctly, let's have a look at the > lease file and compare it with the previous one. The output for resolv.conf is now: domain company.local search company.local nameserver 192.168.0.2 dhclient reported that the lease file already exists so I guess it has not been replaced? Looks the same to me.
Created attachment 345430 [details] new dhclient lease file
I just realized that the following output probably means that a PID file already exists beacause the process is still running: RTNETLINK answers: File exists Should I kill dhclient to get a new lease file?
(In reply to Tilo Villwock from comment #6) > I just realized that the following output probably means that a PID file > already exists beacause the process is still running: > > RTNETLINK answers: File exists > > Should I kill dhclient to get a new lease file? Yes thanks. Maybe also delete (or move somewhere else) the file: /var/lib/dhclient/dhclient.leases , then run dhclient and paste the file content after dhclient succeeds. Just to avoid another round-trip, would you also attach NetworkManager logs? i.e.: # killall dhclient # systemctl start NetworkManager # nmcli general logging level trace # nmcli connection up <connection-name> # journalctl -u NetworkManager --since "-60s" > log.txt Thanks!
So after killing dhclient and removing the leases file in /var/lib/dhcp/ I executed the following command: dhclient -lf /tmp/test.lease enp3s0 and got the following output for resolv.conf: domain company.local search company.local nameserver 192.168.0.2 The contents of test.lease are as follows: lease { interface "enp3s0"; fixed-address 192.168.0.64; option subnet-mask 255.255.255.0; option routers 192.168.0.7; option dhcp-lease-time 604800; option dhcp-message-type 5; option domain-name-servers 192.168.0.2; option dhcp-server-identifier 192.168.0.2; option dhcp-renewal-time 302400; option dhcp-rebinding-time 529200; option domain-name "company.local"; renew 1 2017/02/13 18:39:12; rebind 4 2017/02/16 17:39:46; expire 5 2017/02/17 14:39:46; }
Created attachment 345461 [details] NetworkManager log file After following the steps you listed above I got the output in the attached log file.
Created attachment 345546 [details] [review] [PATCH] dhcp: dhclient: reset the request list if conf file contains 'request' I think this should fix the problem.
(In reply to Beniamino Galvani from comment #10) > Created attachment 345546 [details] [review] [review] > [PATCH] dhcp: dhclient: reset the request list if conf file contains > 'request' > > I think this should fix the problem. This fixed the problem for me. Thank you very much!
(In reply to Beniamino Galvani from comment #10) > Created attachment 345546 [details] [review] [review] > [PATCH] dhcp: dhclient: reset the request list if conf file contains > 'request' > > I think this should fix the problem. lgtm
Applied to master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=f71e1379d6292a94e4b3661fa3aa36cb0150c253 and nm-1-6: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-6&id=78f2ab7cb8446d0d885d32e605d2b0c5122eaf86
Hi all. I'm afraid this patch breaks configurations with dhclient.conf containing any request directive because it masks request routers option which means default gateway isn't set for the connections.
(In reply to Michal Kapar from comment #14) > Hi all. > I'm afraid this patch breaks configurations with dhclient.conf containing > any request directive because it masks request routers option which means > default gateway isn't set for the connections. Can you show a specific example of what you have in dhclient.conf and what the generated configuration file is? Citing 'man dhclient.conf': By default, the DHCPv4 client requests the subnet-mask, broadcast-address, time-offset, routers, domain-search, domain-name, domain-name-servers, host-name, nis-domain, nis-servers, ntp-servers and interface-mtu options while the DHCPv6 client requests the dhcp6 name-servers and domain-search options. Note that if you enter a ´request´ statement, you over-ride these defaults and these options will not be requested.
(In reply to Beniamino Galvani from comment #15) > Can you show a specific example of what you have in dhclient.conf and > what the generated configuration file is? Citing 'man dhclient.conf': I did some tests based on this and the result is: 1) Default debian dhclient.conf contains: request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, domain-search, host-name, dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers, netbios-name-servers, netbios-scope, interface-mtu, rfc3442-classless-static-routes, ntp-servers; The generated dhclient-wlan0.conf strips the directive and contains ... send host-name "XYZ"; # added by NetworkManager option rfc3442-classless-static-routes code 121 = array of unsigned integer 8; option ms-classless-static-routes code 249 = array of unsigned integer 8; option wpad code 252 = string; request; # override dhclient defaults also request subnet-mask; also request broadcast-address; also request time-offset; also request routers; also request domain-name; also request domain-name-servers; also request domain-search; also request host-name; also request dhcp6.name-servers; also request dhcp6.domain-search; also request dhcp6.fqdn; also request dhcp6.sntp-servers; also request netbios-name-servers; also request netbios-scope; also request interface-mtu; also request rfc3442-classless-static-routes; also request ntp-servers; also request ms-classless-static-routes; also request static-routes; also request wpad; 2) My specific dhclient.conf contains this record (to get only specific options from my home network not connected via NM): interface "tap_vpn" { request subnet-mask, broadcast-address, interface-mtu, domain-name-servers; } and the generated dhclient-wlan0.conf then contains: ... interface "tap_vpn" { } send host-name "XYZ"; # added by NetworkManager option rfc3442-classless-static-routes code 121 = array of unsigned integer 8; option ms-classless-static-routes code 249 = array of unsigned integer 8; option wpad code 252 = string; request; # override dhclient defaults also request subnet-mask; also request broadcast-address; also request interface-mtu; also request domain-name-servers; also request rfc3442-classless-static-routes; also request ms-classless-static-routes; also request static-routes; also request wpad; also request ntp-servers; It looks like it applies the request to all interfaces even though it's meant only for a specific one.
Created attachment 346816 [details] [review] [PATCH] dhcp/dhclient: parse "interface" statements (In reply to Michal Kapar from comment #16) > I did some tests based on this and the result is: > 1) Default debian dhclient.conf contains: > > The generated dhclient-wlan0.conf strips the directive and contains The generated configuration should be equivalent to the original one, did you experience any problem in this case? > 2) > It looks like it applies the request to all interfaces even though it's > meant only for a specific one. Correct, NM doesn't understand (yet) the "interface" statement and parses everything enclosed even if the interface doesn't match. This issue was already present before, but probably the effect became more evident when NM started handling the "[also] request" clauses. In attachment a patch to address this issue.
(In reply to Beniamino Galvani from comment #17) > (In reply to Michal Kapar from comment #16) > > I did some tests based on this and the result is: > > 1) Default debian dhclient.conf contains: > > > > The generated dhclient-wlan0.conf strips the directive and contains > > The generated configuration should be equivalent to the original one, > did you experience any problem in this case? No. In this case everything worked as expected (sorry for not being clear). Only the second one caused the problem.
(In reply to Beniamino Galvani from comment #17) > Created attachment 346816 [details] [review] [review] > [PATCH] dhcp/dhclient: parse "interface" statements I don't like all this parsing code, because it fails when unexpected syntax is present. But whatever. The patch lgtm :)
The patch should fix the problem in parsing interfaces. It is now in master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=d405cfd9089f9552969e6a3e1a1c4550fc3c1695 and nm-1-6: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-6&id=7a05d2a228cd6f65e28ff71c9052e1ca55682ce0