Date: Fri, 28 Jul 1995 15:59:59 -0500 (CDT) From: mikebo@tellabs.com To: bugs@freebsd.org Cc: mikebo (Mike Borowiec) Subject: FBSD v2.0.5: NFS to multi-homed servers broken Message-ID: <9507282100.AA05570@tellabk.tellabs.com>
next in thread | raw e-mail | index | archive | help
Greetings -
I've sent messages about this problem to the hackers and questions
lists for a couple weeks now and noone has bothered to reply. Since
it IS a bug, perhaps it will get more attention here...
(Perhaps not... ;v)
A fellow BSDer and myself are both seeing a problem with FreeBSD 2.0.5R
clients that attempt to mount partitions from multi-homed servers (Suns).
It looks like the culprit might be changes made to clnt_udp.c:clntudp_call
to create UDP socket connections. It looks like this change was made to
quickly figure out whether the other end was actually there without
waiting for the timeout. This is different than the Sun RPC method, and
unfortunately, it also breaks in a spectacular way.
On our boxes, mount_nfs can't talk to the portmapper to even figure out
whether NFS is there. Due to the route table on the server, the portmapper
reply may come back with a different source address than the destination
address associated with the connection. In this case the kernel obligingly
drops the packet and sends a port unreachable back to the server. Clearly,
this is BROKEN since, in the case of a multi-homed server, we don't know
*which* interface the reply might come from.
Perhaps it would be better to accept the packet regardless of its source
address, i.e. if the lookup fails in udp_input and inp_faddr is not
INADDR_ANY, try the lookup again with INADDR_ANY, and it would probably
work. Comments anyone...? Am I in the right place, or should I be sending
this bug report directly to "rgrimes", whose May 30 update stamp is in
/usr/src/lib/libc/rpc/clnt_udp.c and pmap_getport.c?
- Mike
PS> I appreciate the good intentions of those that wrote suggesting that
I try the "noconn" option (aka. the "-c" flag to mount_nfs).
Unfortunately, that's *not* the solution to this problem - no effect.
--
--------------------------------------------------------------------------
Michael Borowiec Network Operations Tellabs Operations, Inc.
mikebo@TELLABS.COM 1000 Remington Blvd. MS109
708-378-6007 FAX: 708-378-6714 Bolingbrook, IL, USA 60440
--------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9507282100.AA05570>