From owner-freebsd-hackers  Wed Oct 25 16:59:45 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id QAA01360
          for hackers-outgoing; Wed, 25 Oct 1995 16:59:45 -0700
Received: from hermes.sees.bangor.ac.uk (hermes.sees.bangor.ac.uk [147.143.102.8])
          by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA01346
          ; Wed, 25 Oct 1995 16:59:35 -0700
From: Mr D Whitehead (Ext 2703) <davew@sees.bangor.ac.uk>
Message-Id: <17209.9510252357@hermes.sees.bangor.ac.uk>
Received: from sol (sol.sees.bangor.ac.uk) by hermes.sees.bangor.ac.uk; Thu, 26 Oct 95 00:57:09 BST
Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again!
To: mikebo@tellabs.com
Date: Wed, 25 Oct 1995 23:57:09 +0000 (GMT)
Cc: bugs@freebsd.org, hackers@freebsd.org
In-Reply-To: <199510252043.PAA00582@sunc210.tellabs.com> from "mikebo@tellabs.com" at Oct 25, 95 03:43:18 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2010      
Sender: owner-hackers@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
                  ^^^^^
                  I beg to differ, we are using 2.0.5R (from the CD) and
it _was_ the solution to our problem!

> 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)
> 

-- 
		Dave Whitehead (Computer Support Staff)
-------------------------------------------------------------------------------
EMAIL:-					|	TELEPHONE (work):-
(work) davew@sees.bangor.ac.uk 		|	+44 1248 382703 (Direct line)
(home) 100023.1076@compuserve.com	|	+44 1248 351151 ext 2703
-------------------------------------------------------------------------------
SNAIL MAIL:-
Dave Whitehead
School of Electronic Engineering & Computer Systems,
University College of North Wales,
Dean Street,
Bangor  LL57 1UT
------------------------------------------------------------------------------