Date: Thu, 26 Oct 1995 09:17:03 -0500 (CDT) From: mikebo@tellabs.com To: davew@sees.bangor.ac.uk (Mr D Whitehead) Cc: bugs@freebsd.org, hackers@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! Message-ID: <199510261417.JAA01701@sunc210.tellabs.com> In-Reply-To: <17209.9510252357@hermes.sees.bangor.ac.uk> from "Mr D Whitehead" at Oct 25, 95 11:57:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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 -- -------------------------------------------------------------------------- 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?199510261417.JAA01701>