Date: Tue, 24 Oct 1995 21:45:17 -0500 (CDT) From: mikebo@tellabs.com To: davidg@Root.COM Cc: hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! Message-ID: <9510250245.AA11614@tellabk.tellabs.com> In-Reply-To: <199510250117.SAA27638@corbin.Root.COM> from "David Greenman" at Oct 24, 95 06:17:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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. <Steps up onto soapbox> "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. <Steps down from soapbox> 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 --------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9510250245.AA11614>