Bug 8383 - our dhclient can't handle domain-search
Summary: our dhclient can't handle domain-search
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-13 15:55 CET by Frank Griffin
Modified: 2012-12-26 14:57 CET (History)
3 users (show)

See Also:
Source RPM: dhcp
CVE:
Status comment:


Attachments

Description Frank Griffin 2012-12-13 15:55:05 CET
DHCP has two options for returning "search" data for resolveconf.  One is "domain-name" which has been around forever, and returns a single domain name.  The newer one, although 3 or 4 years old at this point, is "domain-search", which returns a list of domains to be searched in order.

According to the dhclient.conf manpage on the net at http://linux.die.net/man/5/dhclient.conf :

 By default, the DHCPv4 client requests the subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-search, domain-name-servers, host-name, nis-domain, nis-servers, ntp-servers and interface-mtu options

However, according to *our* dhclient man page:

By  default,  the  DHCPv4  client
       requests  the  subnet-mask,  broadcast-address,  time-offset,  routers,
       domain-name, domain-name-servers and host-name options while the DHCPv6
       client requests the dhcp6 name-servers and domain-search options.

In actual use, if you set the dhcpd server to return domain-search rather than domain-name, dhclient will either produce no search line at all in resolv.conf, or (occasionally, and don't ask me how it decides this) it will produce a search line with a single token of the unqualified hostname, e. g. "search ftgme2".

dhcpcd, on the other hand, has no problem with domain-search and produces a correct resolv.conf.  But we use dhclient by default.  We also do not provide a dhclient.conf file, which I assume means that we get only the defaults.

This is particularly annoying because NetworkManager uses dhclient by default, and at present overriding to use dhcpcd doesn't work.

So, the question is, why does our dhclient differ in both behavior and man-page from the version given above ?  If it's old, then it needs to be upgraded.

Possibly related is a post from a year ago at http://lists.freebsd.org/pipermail/freebsd-current/2011-November/029209.html from someone claiming to have created a patch that allows dhclient to handle domain-search.
Manuel Hiebel 2012-12-25 14:58:41 CET

CC: (none) => dmorganec, guillomovitch, thierry.vignaud
Source RPM: dhclient => dhcp

Comment 1 Guillaume Rousse 2012-12-26 14:08:03 CET
The fedora package has been patched to request more options by default:
http://pkgs.fedoraproject.org/cgit/dhcp.git/tree/dhcp-4.2.0-default-requested-options.patch

I just submitted a new dhcp package including this patch.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 2 Frank Griffin 2012-12-26 14:57:37 CET
Thanks !  I'll give this a try today or tomorrow.

Note You need to log in before you can comment on or make changes to this bug.