Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Aug 1995 12:46:25 -0400
From:      Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu>
To:        paul@FreeBSD.ORG
Cc:        current@FreeBSD.ORG
Subject:   Re: workaround for talk's address problem
Message-ID:  <9508081646.AA02790@halloran-eldar.lcs.mit.edu>
In-Reply-To: <199508081616.RAA04464@server.netcraft.co.uk>
References:  <9508081503.AA02688@halloran-eldar.lcs.mit.edu> <199508081616.RAA04464@server.netcraft.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
<<On Tue, 8 Aug 1995 17:16:25 +0100 (BST), Paul Richards <paul@netcraft.co.uk> said:

>> 2) In normal multi-homed environments, this is precisely what
>> you want to do, since you want queries sent on one wire to
>> get replies on the same wire without going through extra
>> router hops as would be required otherwise.

> Not necessarily. You're assuming a "normal multi-homed envirnment"
> is one with two interfaces where you need to do this.

By definition, a ``multi-homed host'' is one with more than one active
interface.

> Multi-homed these days increasingly means having more than one ip
> address aliased to the same interface

No, multi-homed does not mean that and never has.  Your situation is
something completely different, and in particular, it's something with
is NOT REQUIRED TO WORK in the way that you want it to, unlike address
selection for multi-homed hosts which is required to work in the way
that it currently does.

I dare say more people are using FreeBSD to forward packets between
two networks than are ISPs trying to do what you are doing.  Think of
all the questions we get every day about setting up SLIP and PPP...

> This isn't an option. I'd have to modify every possible client that
> could be used and that assumes I have source in the first place.

I'm sorry, but there are no matter of choices.  The code is operating
correctly for a situation where it has to.  If you can find a way to
make it do what you want to do, without breaking what it MUST do, and
without introducing improper knowledge of the networking subsystem
internals into other parts of the system, I'd like to see it.  (I
doubt that it can be done.)

-GAWollman

--
Garrett A. Wollman   | Shashish is simple, it's discreet, it's brief. ... 
wollman@lcs.mit.edu  | Shashish is the bonding of hearts in spite of distance.
Opinions not those of| It is a bond more powerful than absence.  We like people
MIT, LCS, ANA, or NSA| who like Shashish.  - Claude McKenzie + Florent Vollant



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9508081646.AA02790>