NetBSD Problem Report #10319

Received: (qmail 1661 invoked from network); 8 Jun 2000 05:15:30 -0000
Message-Id: <200006080514.AAA01966@birch.eew.tgi.plexus.com>
Date: Thu, 8 Jun 2000 00:14:54 -0500 (CDT)
From: Scott Reynolds <scottr@plexus.com>
Reply-To: scottr@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: NFS_BOOTDHCP fails if DHCP relay honors IP TTL
X-Send-Pr-Version: 3.95

>Number:         10319
>Category:       kern
>Synopsis:       NFS_BOOTDHCP fails if DHCP relay honors IP TTL
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 08 05:16:00 +0000 2000
>Closed-Date:    
>Last-Modified:  Mon Mar 29 20:12:08 +0000 2004
>Originator:     Scott Reynolds
>Release:        20000528
>Organization:
>Environment:
	DNARD, NetBSD/arm32
System: NetBSD shark 1.4Z NetBSD 1.4Z (SHARK) #21: Sun May 28 20:03:12 CDT 2000 root@shark:/amd/toaster.eew.tgi.plexus.com/netbsd/src/sys/arch/arm32/compile/SHARK



>Description:
	The IP TTL in a DHCPDISCOVER broadcast is set to 1 when getting boot
	parameters for a diskless client. If a DHCP relay honors the TTL,
	the broadcast will never reach the server. This behavior has been
	observed with a Cisco IOS 12.0-based layer 3 switch.

	Code inspection reveals the problem fairly quickly.  From
	src/sys/nfs/nfs_bootdhcp.c, line 482:

		/*
		 * Skip the route table when sending on this socket.
		 * If this is not done, ip_output finds the loopback
		 * interface (why?) and then fails because broadcast
		 * is not supported on that interface...
		 */

	Setting SO_DONTROUTE on the socket results in the obvious behavior.

>How-To-Repeat:
	1. Set up a diskless system that uses DHCP to get boot parameters on
	   a network using a Cisco IOS switch/router. Make sure the DHCP
	   server is on a different IP network.
	2. Use "ip helper-address" to configure DHCP relay from the
	   diskless client to the DHCP server.
	3. Try to boot, watch it fail, and note from tcpdump output that
	   the IP TTL is set to 1 for the first set of DHCPDISCOVER
	   broadcasts after the kernel is loaded.

>Fix:
	None provided. Use dhcrelay(8) on another system to work around
	the problem.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: fair 
State-Changed-When: Thu May 22 06:57:54 UTC 2003 
State-Changed-Why:  

The obvious fix is to increase the TTL, either statically, or add 
code to do it incrementally up to some limit. How high should we 
set it, or allow it to go? 

From: Martin Husemann <martin@duskware.de>
To: fair@netbsd.org
Cc: scottr@netbsd.org, kern-bug-people@netbsd.org
Subject: Re: kern/10319
Date: Thu, 22 May 2003 09:53:55 +0200

 On Thu, May 22, 2003 at 06:59:24AM -0000, fair@netbsd.org wrote:
 > The obvious fix is to increase the TTL, either statically, or add
 > code to do it incrementally up to some limit. How high should we
 > set it, or allow it to go?

 I don't see any harm by bumping ttl up to net.inet.ip.ttl. What would
 make this case special for us to care lowering it? A later NFS mount
 would succeed too, right?

 Martin

From: "Erik E. Fair" <fair@netbsd.org>
To: Martin Husemann <martin@duskware.de>
Cc: scottr@netbsd.org, kern-bug-people@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/10319 
Date: Thu, 22 May 2003 01:07:08 -0700

 How far away should a DHCP server be allowed to be for a successful
 query response? Is it safe/secure/wise to allow a DHCP server 30
 hops away to set your IP address?

 Certainly for best NFS performance, you don't want a router inbetween
 the client and the server - latency is bad.

 	Erik <fair@netbsd.org>

From: Martin Husemann <martin@duskware.de>
To: "Erik E. Fair" <fair@netbsd.org>
Cc: scottr@netbsd.org, kern-bug-people@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/10319
Date: Thu, 22 May 2003 10:30:31 +0200

 On Thu, May 22, 2003 at 01:07:08AM -0700, Erik E. Fair wrote:
 > How far away should a DHCP server be allowed to be for a successful
 > query response? Is it safe/secure/wise to allow a DHCP server 30
 > hops away to set your IP address?

 Uhm - not my choice. IIUC the admin must have jumped through hoops
 already to get the DHCP query to the server - so if he did, he probably
 means it. Without a dhcprelay on the router, we will only get one hop,
 or am I missing something?

 Martin

From: Scott Reynolds <scottr@netbsd.org>
To: fair@netbsd.org
Cc: kern-bug-people@netbsd.org, Martin Husemann <martin@duskware.de>
Subject: Re: kern/10319
Date: Tue, 27 May 2003 13:06:26 -0500

 I should think that bumping the IP TTL up to net.inet.ip.ttl as Martin 
 suggests would be acceptable. The DHCP relay already had to be 
 explicitly configured to forward the request to a DHCP server. If we're 
 really paranoid, this could be enabled only with an NFS_BOOT_DHCP_FOO 
 option.

 --scott

State-Changed-From-To: feedback->analyzed 
State-Changed-By: fair 
State-Changed-When: Mon Mar 29 20:07:21 UTC 2004 
State-Changed-Why:  

Here we are, almost a year later, with a suggested change, 
and apparently no action. The NetBSD 2.0 release cycle has 
begun, and it would be nice to resolve this PR before we 
ship. Anyone want to submit a diff? 

>Unformatted:

Home	PR Database Search