From owner-freebsd-bugs Fri Jul 28 14:16:24 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id OAA05177 for bugs-outgoing; Fri, 28 Jul 1995 14:16:24 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id OAA05167 for ; Fri, 28 Jul 1995 14:16:22 -0700 From: mikebo@tellabs.com Received: from tellabk.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0sbwVl-000jC8C; Fri, 28 Jul 95 16:00 CDT Received: by tellabk.tellabs.com (4.1/1.9) id AA05570; Fri, 28 Jul 95 16:00:00 CDT Message-Id: <9507282100.AA05570@tellabk.tellabs.com> Subject: FBSD v2.0.5: NFS to multi-homed servers broken To: bugs@freebsd.org Date: Fri, 28 Jul 1995 15:59:59 -0500 (CDT) Cc: mikebo (Mike Borowiec) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2208 Sender: bugs-owner@freebsd.org Precedence: bulk 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 --------------------------------------------------------------------------