From grog@panic.lemis.com  Thu Jan 21 16:59:42 1999
Received: from panic.lemis.com (panic.lemis.com [192.109.197.149])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA28581
          for <FreeBSD-gnats-submit@freebsd.org>; Thu, 21 Jan 1999 16:59:38 -0800 (PST)
          (envelope-from grog@panic.lemis.com)
Received: (from root@localhost)
	by panic.lemis.com (8.9.2/8.8.8) id LAA01868;
	Fri, 22 Jan 1999 11:29:21 +1030 (CST)
	(envelope-from grog)
Message-Id: <199901220059.LAA01868@panic.lemis.com>
Date: Fri, 22 Jan 1999 11:29:21 +1030 (CST)
From: Greg Lehey <grog@panic.lemis.com>
Reply-To: grog@panic.lemis.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: NFS mounts on dual-homed server may hang
X-Send-Pr-Version: 3.2

>Number:         9612
>Category:       kern
>Synopsis:       NFS mounts on dual-homed server may hang
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    grog
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jan 21 17:00:01 PST 1999
>Closed-Date:    Wed Jan 26 13:04:19 PST 2000
>Last-Modified:  Wed Jan 26 13:06:33 PST 2000
>Originator:     Greg Lehey
>Release:        FreeBSD 4.0-CURRENT i386
>Organization:
LEMIS
>Environment:

	FreeBSD 3.0 or 4.0 system

>Description:

	In this example, panic.lemis.com (192.109.197.149) attempts to
	mount a file system on freebie.lemis.com, which has the
	addresses 139.130.136.133 (PPP interface) and 192.109.197.137
	(Ethernet).  The command is:

	  mount freebie:/T /T

	The resolution of the name `freebie' may be one of the two
	addresses.  If the address is 192.109.197.137, the mount
	completes normally.  If the address is 139.130.136.133, the
	following exchange occurs:

	11:14:44.568928 192.109.197.149.1709389267 > 139.130.136.133.2049: 120 getattr [|nfs]
	11:14:44.569102 192.109.197.137.2049 > 192.109.197.149.1709389267: reply ok 112 read [|nfs]
	11:14:44.569536 192.109.197.149 > 192.109.197.137: icmp: 192.109.197.149 udp port 1022 unreachable
	11:14:44.589909 192.109.197.149.1029 > 139.130.136.133.6000: . ack 5120 win 17376 <nop,nop,timestamp 178539 117902> (DF)
	11:14:45.569932 192.109.197.149.1709389267 > 139.130.136.133.2049: 120 getattr [|nfs]
	11:14:45.570128 192.109.197.137.2049 > 192.109.197.149.1709389267: reply ok 112 read [|nfs]
	11:14:45.570549 192.109.197.149 > 192.109.197.137: icmp: 192.109.197.149 udp port 1022 unreachable
	11:14:47.579700 192.109.197.149.1709389267 > 139.130.136.133.2049: 120 getattr [|nfs]
	11:14:47.579878 192.109.197.137.2049 > 192.109.197.149.1709389267: reply ok 112 read [|nfs]
	11:14:47.580298 192.109.197.149 > 192.109.197.137: icmp: 192.109.197.149 udp port 1022 unreachable

	Here the mount succeeds on the server side, but the reply
	contains the address 192.109.197.137, not 139.130.136.133, and
	is thus rejected by panic.  The mount process hangs in sbwait
	and is not stoppable.

           0  1709     1   0   2  0   340  188 sbwait D     p0    0:00.01 nfs panic:/T (mount_nfs)

	This problem is made worse by the fact that there is no
	possibility of retrying: any subsequent attempt to mount the
	file system fails with the message

	   nfs: /T: Device busy

	This address replacement is not always the case.  For example,
	a ping shows:

	11:14:20.662949 192.109.197.149 > 139.130.136.133: icmp: echo request
	11:14:20.663017 139.130.136.133 > 192.109.197.149: icmp: echo reply

>How-To-Repeat:

	As above

>Fix:
	
	To be investigated


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->grog 
Responsible-Changed-By: grog 
Responsible-Changed-When: Thu Jan 21 17:06:57 PST 1999 
Responsible-Changed-Why:  
I plan to investigate this problem.  It won't be fast. 
If somebody else wants to look at it, be my guest. 
State-Changed-From-To: open->closed 
State-Changed-By: dillon 
State-Changed-When: Wed Jan 26 13:04:19 PST 2000 
State-Changed-Why:  
This problem was solved a few months ago.  The problem is that UDP NFS mounts 
bind to INADDR_ANY.  This can cause a multihomed server to reply to an NFS 
request using a different source address then the address the request was 
sent to.  The solution we committed was to add the '-h' option to 'nfsd'. 
See the manual page for nfsd for a description.   The option allows you to 
bind nfsd to specific IP addresses rather then to INADDR_ANY. 
>Unformatted:
