From owner-freebsd-bugs Fri Oct 27 08:07:04 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA22959 for bugs-outgoing; Fri, 27 Oct 1995 08:07:04 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA22936 ; Fri, 27 Oct 1995 08:06:56 -0700 From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t8qMP-000jBiC; Fri, 27 Oct 95 10:06 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id KAA00739; Fri, 27 Oct 1995 10:06:14 -0500 Message-Id: <199510271506.KAA00739@sunc210.tellabs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Fri, 27 Oct 1995 10:06:13 -0500 (CDT) Cc: mikebo (Mike Borowiec), bugs@freebsd.org, hackers@freebsd.org In-Reply-To: <9510271410.AA22857@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 27, 95 10:10:51 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org Precedence: bulk Garret wrote: > < > I do have a question: > > Would a FreeBSD server always respond to a client from the same interface > > on which it received a request - even though its route table has a > > different route to the clients network? > > No. Source address != interface. If the source address is already > set in the outgoing IP packet, ip_output() will not change it even if > the packet goes out an interface which does not have that address on > it. (Otherwise forwarding would not work!) > So, a multi-homed FreeBSD NFS server would behave the same as a multi- homed Sun NFS server and adhere to the route table. That's what I thought, but is contrary to some grumblings I've heard about the way Sun serves NFS. Some people have sworn that the "proper" thing for the server to do is send replies out the same interface that received the request - evidently not caring whether it adhered to the route table or not. The bottom line is that people mounting filesystems from a multi-homed FreeBSD server could potentially run into the same problem I experienced (NFS replies with a different source addr than the request's destination addr), and be forced to use the "noconn" option. So much for my feeling bad about using those damn rogue Suns. ;v) Since, in this situation, the FreeBSD NFS client doesn't behave according to the "Industry standard" (requires a special option to mount), perhaps this issue should be included in the FAQ. Even though it is not an issue that pops up _frequently_, it is a real hair-puller. Since posting my problem, I've had several people write saying they had the same experience, and it took several days until some kind soul pointed out the deprecated noconn option, which is buried in the mount_nfs man page. Hopefully, deprecated doesn't mean it will be removed anytime soon. ;v) Regards, - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA --------------------------------------------------------------------------