Bug 20525

Summary: Trailing NUL from DHCP server makes dhclient break resolv.conf
Product: Base System Reporter: David Wolfskill <dhw>
Component: binAssignee: David E. O'Brien <obrien>
Status: Closed FIXED    
Severity: Affects Only Me CC: ambrisko
Priority: Normal    
Version: 4.1-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description David Wolfskill 2000-08-10 20:40:00 UTC
	What happens is that the domain name supplied by the server is
	copied into /etc/resolve.conf, but the trailing NUL is *also*
	"copied" -- but represented as "\000".  (For example, one might
	see

		search whistle.com\000

	in /etc/resolv.conf.)

	This causes just about anything that requires a proper domain
	name on the DHCP client machine to fail rather miserably.

Fix: Skipping the above-referenced hack, here's what Doug Ambrisko
	suggested in response to my comment that perhaps dhclient ought
	to be a little more tolerant of what it receives:

From: Doug Ambrisko <ambrisko@whistle.com>
Message-Id: <200007271838.LAA42370@whistle.com>
Subject: Re: 4.1-RC heads up on dhclient
To: David Wolfskill <dhw@whistle.com>
Date: Thu, 27 Jul 2000 11:38:39 -0700 (PDT)

David Wolfskill writes:
| Perhaps the dhclient should be fixed to be a bit more tolerant -- possibly
| in addition to anything else.  After all, I'd not expect a NUL to be a
| valid character in a domain name....  :-}

Here it is, feel free to submit this on my behalf.  I've tried it against
alpo and a good dhcp server and it appears to work.

Doug A.

In reviewing that, it occurred to me that the above could still
	break if there were multiple trailing NULs.  Granted, that's
	pathological, but this would fix that, I think (though I haven't
	tested it):



All that aside, it would probably be better to scan from the
	left side of the domain name, and stop if either "len" is
	reached or a character is read that is invalid in a domain name.--eKDxYGKTecLRw1ip3p2oFdh0ngduJL5uzASJUgVV2WIObYgi
Content-Type: text/plain; name="file.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="file.diff"

Index: common/options.c
===================================================================
RCS file: /cvs/freebsd/src/contrib/isc-dhcp/common/options.c,v
retrieving revision 1.1.1.3.2.1
diff -c -r1.1.1.3.2.1 options.c
*** options.c	2000/06/26 23:07:21	1.1.1.3.2.1
--- options.c	2000/07/27 18:37:23
***************
*** 492,497 ****
--- 492,499 ----
  			fmtbuf [i] = 't';
  			fmtbuf [i + 1] = 0;
  			numhunk = -2;
+ 			/* accept null-terminated string */
+ 			if(len && !dp[len-1]) len--; 
  			break;
  		      case 'I':
  		      case 'l':
How-To-Repeat: 
	Well, you need such a broken/misfeatured DHCP server, first.
	Unfortunately, the DHCP server supplied in the Whistle InterJet
	is one such:  Archie was the one who pointed out that the server
	had been modified to support certain Microsoft clients (which
	he identified, but I failed to keep a copy of that note) that
	would otherwise break.

	Once that's done, just fire up a FreeBSD box as a DHCP client.
	(Note:  It is *not* fair to hand-edit /etc/resolve.conf, and
	then issue "chflags schg /etc/resolv.conf".  This is considered
	un-sporting in the extreme; it's one of the ways I circumvent
	the problem....)

	After the multi-user boot finishes, take a look at
	/etc/resolv.conf.
Comment 1 Sheldon Hearn freebsd_committer freebsd_triage 2000-08-11 10:54:20 UTC
Responsible Changed
From-To: freebsd-bugs->obrien

Over to the maintainer.
Comment 2 David E. O'Brien freebsd_committer freebsd_triage 2000-08-11 13:09:13 UTC
State Changed
From-To: open->closed

Ted Lemon (ISC DHCP author) has said this patch is not needed, as the 
DHCP server sending this out is non-RFC complaiant.  Nor will he make this 
type of change in ISC DHCP version 3.  (ver 2 is in only security bug fix mode) 

I will not make changes to our dhclient offering that is way out wack with 
what the offical ISC offering does, esp. when Ted finds it the Wrong 
Thing to do.