From dhw@whistle.com  Thu Aug 10 12:39:04 2000
Return-Path: <dhw@whistle.com>
Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64])
	by hub.freebsd.org (Postfix) with ESMTP id 805AC37BA6D
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 10 Aug 2000 12:39:03 -0700 (PDT)
	(envelope-from dhw@whistle.com)
Received: (from dhw@localhost)
	by pau-amma.whistle.com (8.9.3/8.9.3) id MAA21273;
	Thu, 10 Aug 2000 12:39:03 -0700 (PDT)
	(envelope-from dhw)
Message-Id: <200008101939.MAA21273@pau-amma.whistle.com>
Date: Thu, 10 Aug 2000 12:39:03 -0700 (PDT)
From: David Wolfskill <dhw@whistle.com>
Reply-To: dhw@whistle.com
To: FreeBSD-gnats-submit@freebsd.org
Cc: ambrisko@whistle.com, archie@whistle.com
Subject: Trailing NUL from DHCP server makes dhclient break resolv.conf
X-Send-Pr-Version: 3.2

>Number:         20525
>Category:       bin
>Synopsis:       Trailing NUL from DHCP server makes dhclient break resolv.conf
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    obrien
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Thu Aug 10 12:40:00 PDT 2000
>Closed-Date:    Fri Aug 11 05:09:13 PDT 2000
>Last-Modified:  Fri Aug 11 05:11:30 PDT 2000
>Originator:     David Wolfskill
>Release:        FreeBSD 4.1-STABLE i386
>Organization:
Whistle Communications
>Environment:

	Running FreeBSD as a DHCP client, where the DHCP server in
	question has been set up to provide a trailing NUL in the
	supplied domain name (for broken DHCP clients that treat
	the domain name as a "C string").

>Description:

	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.

>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.

>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.

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':


	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):

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 */
+ 			while (len && !dp[len-1]) len--; 
  			break;
  		      case 'I':
  		      case 'l':


	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.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->obrien 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Fri Aug 11 02:54:20 PDT 2000 
Responsible-Changed-Why:  
Over to the maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=20525 
State-Changed-From-To: open->closed 
State-Changed-By: obrien 
State-Changed-When: Fri Aug 11 05:09:13 PDT 2000 
State-Changed-Why:  
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. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=20525 
>Unformatted:
