From owner-freebsd-bugs  Wed Oct 25 13:44:30 1995
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id NAA13192
          for bugs-outgoing; Wed, 25 Oct 1995 13:44:30 -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 NAA13187
          ; Wed, 25 Oct 1995 13:44:25 -0700
From: mikebo@tellabs.com
Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp
	(Smail3.1.29.1 #4) id m0t8CfU-000jBzC; Wed, 25 Oct 95 15:43 CDT
Received: by sunc210.tellabs.com (SMI-8.6/1.9)
	id PAA00582; Wed, 25 Oct 1995 15:43:19 -0500
Message-Id: <199510252043.PAA00582@sunc210.tellabs.com>
Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again!
To: wollman@lcs.mit.edu (Garrett A. Wollman)
Date: Wed, 25 Oct 1995 15:43:18 -0500 (CDT)
Cc: bugs@freebsd.org, hackers@freebsd.org, davew@sees.bangor.ac.uk
In-Reply-To: <9510251423.AA07418@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 25, 95 10:23:33 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

Garrett wrote:
> Actually, connect(2) is what is presently being done and part of what
> causes the breakage.  From mount_nfs(8):
> 
>      -c      For UDP mount points, do not do a connect(2).  This must be used
>              for servers that do not reply to requests from the standard NFS
>              port number 2049.
> 
> Unfortunately, I don't believe that even this option will help, since
> the problem is that the server is replying from an address that the
> client has no way of knowing represents the same host.  But it may be
> worth a try.  (This option can also be accessed through the deprecated
> syntax `noconn'.)
> 
Wahoo! This option did the trick, even though the ip_addrs didn't match.
This option did _not_ work under 2.0.5R, due to bad hackage of the RPC
code in libc. It does seem to work under 2.1.0-951020-SNAP! Come to
think of it, the "bad hackage" was, in fact, a connect() being done in
lib/libc/rpc/clnt_udp.c.

Hopefully, now that we know this is a workaround for strict 4.4BSD net
security, the "-o noconn" option will not be removed. I must admit I
don't understand why a connect(2) is being done. Isn't UDP a connection-
LESS protocol? Perhaps someone can explain... I am only an egg. ;v)

Thanks everyone for your suggestions!
- 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
--------------------------------------------------------------------------