Description of problem: dhclient doesn't filter unicode terminating character \000 when creating /etc/resolv.conf search order from DHCP response package. Version-Release number of selected component (if applicable): dhclient-3.0.1-10_EL3 How reproducible: You need some new unicode windows server to serve as DHCP server (w2k?). Steps to Reproduce: 1. Configure the network as bootproto=dhcp 2. ifup <network interface> 3. cat /etc/resolv.conf Actual results in resolv.conf to be something like: search sub1.mydomain.com\000 sub2.mydomain.com sub3.mydomain.com nameserver 172.16.1.1 nameserver 172.16.2.2 Expected results: search sub1.mydomain.com sub2.mydomain.com sub3.mydomain.com nameserver 172.16.1.1 nameserver 172.16.2.2 Additional information: ftp://ftp.rfc-editor.org/in-notes/rfc2132.txt 2. BOOTP Extension/DHCP Option Field Format ... All other options are variable-length with a length octet following the tag octet. The value of the length octet does not include the two octets specifying the tag and length. The length octet is followed by "length" octets of data. Options containing NVT ASCII data SHOULD NOT include a trailing NULL; however, the receiver of such options MUST be prepared to delete trailing nulls if they exist. The receiver MUST NOT require that a trailing null be included in the data. In the case of some variable-length options the length field is a constant but must still be specified. This is an old and well known issue: http://www.google.fi/search?hl=fi&q=resolv.conf+%22%5C000%22&btnG=Hae&meta=
This issue can be duplicated with an ISC DHCP server, eg. with this in dhcpd.conf: ' ... domain-name "sub1.net\000 sub2.net\000"; ' The code DOES strip the TRAILING null from the whole option, so if the domain-name option value above was sent, the client would write: "search sub1.net\000 sub2.net " to /etc/resolv.conf. The domain-name search path is sent as one option, and trailing NULLs ARE stripped from it. Now, it is arguable whether or not the RFC is breached by the server putting nulls in the middle of an option value as above. This should probably be allowed, as some people might actually want to use unicode or UTF-8 domain names which may contain 00 bytes - there is no hard specification which states that domain names MUST NOT contain bytes of any value - only recommendations that they SHOULD be restricted to the ASCII or proper UTF-8 / unicode sets . I'd advise you contact your server administrator to get them to clean up the domain-name option they are sending - it should not contain nulls in the middle of the option. If the server won't co-operate, you can fix this with the following lines in /etc/dhclient-script, in the "make_resolv_conf" function: if [ -n "$new_domain_name" ]; then new_domain_name=${new_domain_name//\\000}; fi I've contacted the ISC DHCP developers to seek their opinion on this issue, and will take action if they agree this is a bug - but I think they'll probably say it is not a bug because the TRAILING nulls are stripped as required in the RFC and unicode/UTF-8 domain names must be supported.
> Now, it is arguable whether or not the RFC is breached by the server > putting nulls in the middle of an option value as above. Actually, it looks that this case the problem is caused by execution order. When the server response is appended with string configured to /etc/dhclient-eth0.conf (contains known corporate domains), the NULL stripping is performed *after* the additional domains are concatenated, not *before*. This causes that broken DHCP response gets buried in the middle of string and is never cleared as RFC advices. This is clear bug, stripping should happen for the plain DHCP answer as local filesystem is not likely to contain such garbage as it's not typically modified on the fly.
OK, sorry, it wasn't clear that the problem happens when you specify 'append domain-name " my.domain.com" ' in dhclient.conf. So, to be clear, the server sends : 'option domain-name "this.domain.com\000";' the client then appends its domain in dhclient.conf, and you end up with 'domain-name "this.domain.com\000 my.domain.com"' - that is not nice. I'll implement the fix to strip trailing nulls before dhclient.conf option processing.
I did'nt know that either. My colleague figured that out and tipped it just recently. I confirm the above description. Thank you, we look forward to this disapper for good. :)
This bug is now fixed with dhcp-3.0.1-42_EL3 (the next RHEL-3 update release for dhcp) and with dhcp-3.0.3-3_EL3 (for those customers who want dhcp-3.0.3 features on RHEL-3, but which will NOT be in any RHEL-3 update release). Both these releases are available at: http://people.redhat.com/~jvdias/dhcp/RHEL-3 dhcp-3.0.1-42_EL3 will hopefully be in RHEL-3-U7 . It is also fixed in the Rawhide dhcp-3.0.3-3 release, in dhcp-3.0.3-3_FC4 for FC4, and in dhcp-3.0.1-42_EL4 and dhcp-3.0.3-3_EL4 for RHEL-4. ISC bug 15293 has been raised on this issue, which will hopefully be fixed in future upstream dhcp releases from the ISC.
Closing as WONTFIX. dhcp-3.0.1-10_EL3 is the latest version shipped for RHEL-3.