Red Hat Bugzilla – Bug 160655
dhclient violates DHCP RFC when response includes unicode \000
Last modified: 2010-04-06 09:13:45 EDT
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):
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
search sub1.mydomain.com sub2.mydomain.com sub3.mydomain.com
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:
This issue can be duplicated with an ISC DHCP server, eg. with this
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
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
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
> 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"
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
I did'nt know that either. My colleague figured that out and tipped it just
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:
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.