From owner-freebsd-hackers  Thu Oct 26 15:08:50 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id PAA29839
          for hackers-outgoing; Thu, 26 Oct 1995 15:08:50 -0700
Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28])
          by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA29801
          ; Thu, 26 Oct 1995 15:08:29 -0700
From: mikebo@tellabs.com
Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp
	(Smail3.1.29.1 #4) id m0t8aSZ-000jCvC; Thu, 26 Oct 95 17:07 CDT
Received: by sunc210.tellabs.com (SMI-8.6/1.9)
	id RAA00763; Thu, 26 Oct 1995 17:07:34 -0500
Message-Id: <199510262207.RAA00763@sunc210.tellabs.com>
Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again!
To: faulkner@mpd.tandem.com (Boyd Faulkner)
Date: Thu, 26 Oct 1995 17:07:33 -0500 (CDT)
Cc: mikebo (Mike Borowiec), davidg@Root.COM, hackers@freebsd.org,
        bugs@freebsd.org
In-Reply-To: <9510261811.AA28231@olympus> from "Boyd Faulkner" at Oct 26, 95 01:11:43 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
Precedence: bulk

Boyd wrote:
> Is this your rpc problem again, or are you past that now?  Last time you
> had problems of this sort, I recommended using the noconn option for NFS.
> It was not the solution for you last time but the symptoms I see here seem
> more in line with this fix.  You mount and then all packets start coming
> from another interface.  Using noconn, keeps you from connecting until you
> know about the new interface.  I hope this works for you this time.
> 
--------------------------------------------------------------------------
PROBLEM DEFINITION:
Server: Multi-homed Sun server running routed (receiving routes via RIP)
Client: distant FreeBSD 2.x client (not on any of the servers ethernets)

The Server's IP route to Client's network is unknown, and may change
whenever the Server receives a RIP update from router. The following
scenarios assume that: 
1) The client is not on any network to which the server has a direct
   ethernet connection.
2) Packets arrive from the client on server's ethernet interface 'A'.
3) The server's route table contains a route to the client's network.
4) The route in 3) causes packets sent to the client to leave server's
   ethernet interface 'B'. Result: reply source address is different
   than request destination address.

Under 2.0.5R (with or without noconn option):
MOUNT command hangs unkillable on Client. Client reaction: ICMP message
"Destination unreachable (Bad port)" sent to responding IP address.

Under 2.1.0-951020-SNAP (without noconn option):
MOUNT command completes OK. Provided no other access to the file-
system are attempted first, UMOUNT also completes OK. However, any
commands which access the now mounted filesystem (such as df or ls)
hang unkillable and file system can not be UMOUNTED. Client reaction:
ICMP message "Destination unreachable (Bad port)" sent to responding
IP address.

Under 2.1.0-951020-SNAP (with noconn option):
MOUNT and UMOUNT command completes OK. All accesses to mounted
filesystem complete OK. Everything appears OK. This is the normal
behaviour of most major commercial UNIX and UNIX-like OSes.
--------------------------------------------------------------------------
Hopefully, this is the last time I need to document this. ;v)

I do have a question:
Would a FreeBSD server always respond to a client from the same interface
on which it received a request - even though its route table has a
different route to the clients network?
- 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
--------------------------------------------------------------------------