Date: Thu, 26 Oct 1995 17:07:33 -0500 (CDT) From: mikebo@tellabs.com To: faulkner@mpd.tandem.com (Boyd Faulkner) Cc: mikebo (Mike Borowiec), davidg@Root.COM, hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! Message-ID: <199510262207.RAA00763@sunc210.tellabs.com> In-Reply-To: <9510261811.AA28231@olympus> from "Boyd Faulkner" at Oct 26, 95 01:11:43 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Boyd wrote: > Is this your rpc problem again, or are you past that now? Last time you > had problems of this sort, I recommended using the noconn option for NFS. > It was not the solution for you last time but the symptoms I see here seem > more in line with this fix. You mount and then all packets start coming > from another interface. Using noconn, keeps you from connecting until you > know about the new interface. I hope this works for you this time. > -------------------------------------------------------------------------- PROBLEM DEFINITION: Server: Multi-homed Sun server running routed (receiving routes via RIP) Client: distant FreeBSD 2.x client (not on any of the servers ethernets) The Server's IP route to Client's network is unknown, and may change whenever the Server receives a RIP update from router. The following scenarios assume that: 1) The client is not on any network to which the server has a direct ethernet connection. 2) Packets arrive from the client on server's ethernet interface 'A'. 3) The server's route table contains a route to the client's network. 4) The route in 3) causes packets sent to the client to leave server's ethernet interface 'B'. Result: reply source address is different than request destination address. Under 2.0.5R (with or without noconn option): MOUNT command hangs unkillable on Client. Client reaction: ICMP message "Destination unreachable (Bad port)" sent to responding IP address. Under 2.1.0-951020-SNAP (without noconn option): MOUNT command completes OK. Provided no other access to the file- system are attempted first, UMOUNT also completes OK. However, any commands which access the now mounted filesystem (such as df or ls) hang unkillable and file system can not be UMOUNTED. Client reaction: ICMP message "Destination unreachable (Bad port)" sent to responding IP address. Under 2.1.0-951020-SNAP (with noconn option): MOUNT and UMOUNT command completes OK. All accesses to mounted filesystem complete OK. Everything appears OK. This is the normal behaviour of most major commercial UNIX and UNIX-like OSes. -------------------------------------------------------------------------- Hopefully, this is the last time I need to document this. ;v) 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? - 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 --------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510262207.RAA00763>