From owner-freebsd-hackers  Thu Oct 26 12:24:00 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id MAA19308
          for hackers-outgoing; Thu, 26 Oct 1995 12:24:00 -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 MAA19291
          ; Thu, 26 Oct 1995 12:23:57 -0700
Received: from olympus by devnull (8.6.8/8.6.6)
	id OAA00203; Thu, 26 Oct 1995 14:23:14 -0500
Received: by olympus (4.1/TSS2.1)
	id AA28585; Thu, 26 Oct 95 14:23:11 CDT
From: faulkner@mpd.tandem.com (Boyd Faulkner)
Message-Id: <9510261923.AA28585@olympus>
Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again!
To: mikebo@tellabs.com
Date: Thu, 26 Oct 1995 14:23:10 -0500 (CDT)
Cc: davew@sees.bangor.ac.uk, bugs@freebsd.org, hackers@freebsd.org
In-Reply-To: <199510261417.JAA01701@sunc210.tellabs.com> from "mikebo@tellabs.com" at Oct 26, 95 09:17:03 am
X-Mailer: ELM [version 2.4 PL17]
Content-Type: text
Content-Length: 1696      
Sender: owner-hackers@freebsd.org
Precedence: bulk

> 
> Dave wrote:
> > > 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.
> > > > 
> > > 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.
> > 
> I did try "noconn" while monitoring with snoop and a Sniffer, and under
> 2.0.5R (from the CD also), it did not solve the problem of differing
> ip_addrs. My traces showed ICMP Destination unreachable (Bad port) with
> or without noconn. But, there's no arguing with results. I couldn't get
> it to work, and documented it months ago. No sense going back now...
> - Mike
> -- 
I remember seeing it, too.  Oddly enough, the rpc problem did not affect 
amd which was handling my mounts.  (I was already running with noconn.)  But, if
I tried to connect with mount, it would fail.

Boyd


-- 
_______________________________________________________________________

 Boyd Faulkner - faulkner@isd.tandem.com - http://cactus.org/~faulkner
_______________________________________________________________________