Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 160655

Summary: dhclient violates DHCP RFC when response includes unicode \000
Product: Red Hat Enterprise Linux 3 Reporter: Juha Tuomala <tuomala>
Component: dhcpAssignee: Jiri Popelka <jpopelka>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-04-06 13:13:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Juha Tuomala 2005-06-16 13:21:01 UTC
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):


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:


Expected results:


Additional information:
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:

Comment 1 Jason Vas Dias 2005-06-16 18:43:52 UTC
This issue can be duplicated with an ISC DHCP server, eg. with this
in dhcpd.conf:
'  ...
   domain-name "\000\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:
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

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.

Comment 2 Juha Tuomala 2005-08-16 11:26:40 UTC
> 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.

Comment 3 Jason Vas Dias 2005-08-16 14:58:34 UTC
OK, sorry, it wasn't clear that the problem happens when you specify 
  'append domain-name ""
in dhclient.conf.

So, to be clear, the server sends :
  'option domain-name "\000";'
the client then appends its domain in dhclient.conf, and you end up with
  'domain-name "\000"' -
that is not nice.

I'll implement the fix to strip trailing nulls before dhclient.conf option 

Comment 4 Juha Tuomala 2005-08-17 05:36:54 UTC
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. :)

Comment 5 Jason Vas Dias 2005-08-23 17:21:12 UTC
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.

Comment 9 Jiri Popelka 2010-04-06 13:13:45 UTC
Closing as WONTFIX. dhcp-3.0.1-10_EL3 is the latest version shipped for RHEL-3.