From owner-freebsd-hackers Thu Oct 26 11:12:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA16671 for hackers-outgoing; Thu, 26 Oct 1995 11:12:23 -0700 Received: from devnull (devnull.mpd.tandem.com [131.124.4.29]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA16663 ; Thu, 26 Oct 1995 11:12:20 -0700 Received: from olympus by devnull (8.6.8/8.6.6) id NAA24979; Thu, 26 Oct 1995 13:11:37 -0500 Received: by olympus (4.1/TSS2.1) id AA28231; Thu, 26 Oct 95 13:11:44 CDT From: faulkner@mpd.tandem.com (Boyd Faulkner) Message-Id: <9510261811.AA28231@olympus> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: mikebo@tellabs.com Date: Thu, 26 Oct 1995 13:11:43 -0500 (CDT) Cc: davidg@Root.COM, hackers@freebsd.org, bugs@freebsd.org In-Reply-To: <9510250245.AA11614@tellabk.tellabs.com> from "mikebo@tellabs.com" at Oct 24, 95 09:45:17 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 4392 Sender: owner-hackers@freebsd.org Precedence: bulk Mike, 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. Boyd > > David G. wrote: > > Mike Borowiec wrote: > > >The following is Solaris snoop output which shows the problem. TOYBOX > > >is running 2.1.0-951020-SNAP and TELLABK (aka SUNK) is a multi-homed > > >server running SunOS 4.1.3 and "routed -q". First we do the mount: > > > > > ># mount tellabk:/export/home/tellabk-4 /usr/home > > > > > > toybox -> tellabk PORTMAP C GETPORT prog=100003 (NFS) vers=2 proto=UDP > > > sunk -> toybox PORTMAP R GETPORT port=2049 > > > toybox -> tellabk PORTMAP C GETPORT prog=100005 (MOUNT) vers=1 proto=UDP > > > sunk -> toybox PORTMAP R GETPORT port=737 > > > toybox -> tellabk MOUNT C Mount /export/home/tellabk-4 > > > sunk -> toybox MOUNT R Mount OK F=075B > > > > > >Looks like the mount completed OK, even though the replies came from SUNK, > > >TELLABK's alter-ego. So let's do a "df": > > > > Yeah, that's the problem. This doesn't look like a FreeBSD problem to me - > > it looks like the Sun is replying out a different interface then it received > > the mount request from. FreeBSD rightfully thinks this is crap coming from > > some irrelevant machine. I think you should be able to work around it by using > > the name/address of "sunk" when doing the mount. > > > Yes, the Sun is replying from a different interface than it received > the mount request from. That's because the Sun is running "routed" and > learns its route back to TOYBOX from a RIP announcement made by a router. > Using the name/addr of SUNK may work today - what if tomorrow the router > decides TELLABK is best, or SUNK2, or SUNK3, etc. > > > "Correct" or not, Suns do not always reply back on the same interface > from which they receive a request. It is basically a crap-shoot... Worse, > if the router dynamically changes the route back to TOYBOX, for whatever > reason (down interface, route optimization), the Sun will dutifully begin > replying on a new interface as soon as the RIP announcement is received. > > This isn't something that can be changed on a Sun. Even configuring a > Sun with static routes won't really solve the problem, as someone/sometime > is bound to request a mount from an interface which is not the server's > default route. In that case, the reply would come from the interface > tagged with the default route. The onus is on the client to deal with it... > > This situation is correctly handled by every commercial UNIX OS I've > worked with. I don't know what security implications that has, but I > do know that FreeBSD's NFS (and so the whole OS) is useless to me > (and others running in a similar environment) unless it works with > Suns and plays by their rules. If I can't use the OS, the security > doesn't do me a damn bit of good! > > I can document this behavior in SunOS, Solaris and HP/UX if it will > help strengthen the argument. This is the real world behavior, and I'm > inclined to believe that FreeBSD is not in a position to dictate what's > "proper behaviour" to Sun (the progenitors of RPC and NFS) and the rest > of the commerical UNIX market. > > > Sorry for the rambling discourse, but I need this fixed or I can't > use FreeBSD. At the least, can the "Sun behavior" I need be added > as an option to the mount command? > - 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 > -------------------------------------------------------------------------- > -- _______________________________________________________________________ Boyd Faulkner - faulkner@isd.tandem.com - http://cactus.org/~faulkner _______________________________________________________________________