Bug 22594

Summary: NFS can't handle asymmetric server routing
Product: Base System Reporter: peter.jeremy <peter.jeremy>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 5.0-CURRENT   
Hardware: Any   
OS: Any   

Description peter.jeremy 2000-11-04 01:30:01 UTC
	Given the following network configuration.  If the server
	routes to the client via router-3 and the client attempts
	to NFS mount a filesystem via server-2, the mount will
	block indefinitely.

	              +------+  -2  +------+
	+------+  -1  |      |------|      |
	|client|------|router|      |server|
	+------+      |      |------|      |
	              +------+  -3  +------+

	For example "mount server-2:/cdrom /cdrom" produces the
	following network packets:
	
12:16:32.119294 client-1.976 > server-2.111:  udp 56
12:16:32.303056 server-2.111 > client-1.976:  udp 28
12:16:32.305913 client-1.975 > server-2.111:  udp 56
12:16:32.481473 server-3.111 > client-1.975:  udp 28
12:16:32.488073 client-1.855771785 > server-2.2049: 40 null
12:16:32.652983 server-2.2049 > client-1.855771785: reply ok 24 null
12:16:32.656422 client-1.973 > server-2.111:  udp 56
12:16:32.821607 server-3.111 > client-1.973:  udp 28
12:16:32.831160 client-1.972 > server-2.1017:  udp 124
12:16:33.111041 server-2.1017 > client-1.972:  udp 68
12:16:33.180257 client-1.1718190197 > server-2.2049: 124 access fh 117,2/3 003f
12:16:33.421336 server-3.2049 > client-1.1718190197: reply ok 120 proc-135571692
12:16:33.422329 client-1 > server-3: icmp: client-1 udp port 971 unreachable

	The last 3 packets repeat indefinitely (with exponential backoff).

	When I change the routing on the server so packets for client-1
	go via server-2 instead, it recovers and completes the mount:

12:17:44.046144 client-1.1718190197 > server-2.2049: 124 access fh 117,2/3 003f
12:17:44.247190 server-2.2049 > client-1.1718190197: reply ok 120 access c 0023

Fix: 

Unknown.  The client is correct to reject the packets from an
	(unknown) server.  The server should be using a source address
	that matches the address that the client requested to mount.
How-To-Repeat: 
	Set up network and issue mount command as per above.
Comment 1 dwmalone 2000-11-04 09:16:51 UTC
On Sat, Nov 04, 2000 at 12:28:21PM +1100, Peter Jeremy wrote:

> 	Unknown.  The client is correct to reject the packets from an
> 	(unknown) server.  The server should be using a source address
> 	that matches the address that the client requested to mount.

I think you can fix this by using the -h option in nfsd. For each
address you want to do UDP based serving on give a -h option. For
example we use something like:

nfsd -u -t -n 4 -a -h 10.0.1.1 -h 10.0.2.1

for a machine that does NFS on two different ethernet cards.

	David.
Comment 2 dwmalone freebsd_committer freebsd_triage 2000-11-07 09:56:34 UTC
State Changed
From-To: open->feedback

Any luck with the -h option to nfsd? 

David.
Comment 3 Bruce A. Mah freebsd_committer freebsd_triage 2001-11-17 18:39:12 UTC
State Changed
From-To: feedback->closed

Feedback timeout (12 months).
Comment 4 Eric Anderson 2003-03-11 22:48:51 UTC
This fix works for the NFS server side, but from the client side, there 
is no way (that I know of) that allows you to allow this behavior.  In 
other words, if I have a Solaris NFS server (that incorrectly responds 
on a different interface with the wrong source address), my FreeBSD NFS 
client hangs.  I have submitted a PR for this long ago, and was told 
"too bad - they didn't follow the specs", but the reality is that the 
FreeBSD mount command (and amd for that matter) should have a bypass to 
say "I don't care if it comes back from a different source address, take 
it anyway" - so it will work.  I know it is a security risk, but I 
should be able to enable that if I'd like.

This PR should be re-opened.

Eric


-- 
------------------------------------------------------------------
Eric Anderson	   Systems Administrator      Centaur Technology
Attitudes are contagious, is yours worth catching?
------------------------------------------------------------------