From nobody@FreeBSD.org  Thu Jan  3 12:12:38 2002
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 4306A37B41B
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  3 Jan 2002 12:12:38 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id g03KCcX53390;
	Thu, 3 Jan 2002 12:12:38 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200201032012.g03KCcX53390@freefall.freebsd.org>
Date: Thu, 3 Jan 2002 12:12:38 -0800 (PST)
From: Eric Anderson <anderson@centtech.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: amd incorrectly handles multi-homed nfs servers - causing failures
X-Send-Pr-Version: www-1.0

>Number:         33515
>Category:       bin
>Synopsis:       amd incorrectly handles multi-homed nfs servers - causing failures
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    mbr
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jan 03 12:20:01 PST 2002
>Closed-Date:    Tue Jul 06 14:16:56 GMT 2004
>Last-Modified:  Tue Jul 06 14:16:56 GMT 2004
>Originator:     Eric Anderson
>Release:        FreeBSD RELEASE 4.x
>Organization:
Centaur Technology
>Environment:
FreeBSD proton.centtech.com 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Fri Sep  7 09:42:10 CDT 2001     root@proton.centtech.com:/usr/src/sys/compile/PROTON  i386
>Description:
I have a FreeBSD client on net A, and a multi-homed NFS server (running Linux, or
Solaris, take your pick) on nets A and B.  If I attempt to access the server
with automounter (amd) via the interface that is NOT on my net (A), it times
out, responding with:
nfs server pid226@clienthostname:/net: not responding
nfs server pid226@clienthostname:/net: is alive again
ls: /net/inside/usr2: No such file or directory 

Also, this may be unrelated, but it's still odd (and probably somehow
exploitable).  Hard to explain, but I'll do my best. 
If, on a client, I try to do a 'cd /net/server1/' to a NIC (on the server) that
will timeout (as mentioned above), and as soon as it starts timing out, I do
ctrl-C to break from it, and open another window and do a 'cd
/net/server2/share/', when the first 'cd' command finally breaks, it will drop
to a /net/server2/share/ directory, instead of the original working directory..
So it sounds kind of like the NFS handles are being reused too quickly or
something like that.
>How-To-Repeat:
On a FreeBSD 4.x client (with NFS client and amd enabled), access an automount on a server that is on two networks.  You must access the nic that is NOT on the same network as the client.

This has been mentioned before, but has not been corrected. See PR # 4705.


>Fix:
      
>Release-Note:
>Audit-Trail:

From: Ian Dowse <iedowse@maths.tcd.ie>
To: Eric Anderson <anderson@centtech.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/33515: amd incorrectly handles multi-homed nfs servers - causing failures 
Date: Fri, 04 Jan 2002 01:05:42 +0000

 In message <200201032012.g03KCcX53390@freefall.freebsd.org>, Eric Anderson writ
 es:
 >I have a FreeBSD client on net A, and a multi-homed NFS server (running Linux,
 > or
 >Solaris, take your pick) on nets A and B.  If I attempt to access the server
 >with automounter (amd) via the interface that is NOT on my net (A), it times
 >out, responding with:
 
 This sounds like the common server-side bug where the server responds
 from the wrong IP address. I'm not sure if Linux or Solaris have a
 way to avoid this, but when using FreeBSD as the NFS server, just
 add "-h bindip" options to nfsd for each IP address on the server.
 
 The workaround for servers that cannot be made use the correct
 source address is simply to use the address that works. I don't
 think that FreeBSD can do much more here without resorting to the
 insecure approach of accepting replies from any address at all.
 
 >If, on a client, I try to do a 'cd /net/server1/' to a NIC (on the server) tha
 >t
 >will timeout (as mentioned above), and as soon as it starts timing out, I do
 >ctrl-C to break from it, and open another window and do a 'cd
 >/net/server2/share/', when the first 'cd' command finally breaks, it will drop
 >to a /net/server2/share/ directory, instead of the original working directory.
 >.
 >So it sounds kind of like the NFS handles are being reused too quickly or
 >something like that.
 
 Weird, that is probably a real amd bug.
 
 Ian
Responsible-Changed-From-To: freebsd-bugs->mbr 
Responsible-Changed-By: mbr 
Responsible-Changed-When: Thu May 13 01:04:31 PDT 2004 
Responsible-Changed-Why:  
Take this PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=33515 
State-Changed-From-To: open->feedback 
State-Changed-By: mbr 
State-Changed-When: Tue Jul 6 13:52:05 GMT 2004 
State-Changed-Why:  
Hi, 

Is this still a problem with recent FreeBSD versions ? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=33515 
State-Changed-From-To: feedback->closed 
State-Changed-By: mbr 
State-Changed-When: Tue Jul 6 14:15:53 GMT 2004 
State-Changed-Why:  
According to the orig. submitter this PR is not a problem anymore. 

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