Date: Mon, 7 Aug 1995 12:09:46 -0700 From: Pete Carah <pete@puffin.pelican.com> To: current@FREEBSD.org Subject: Re: workaround for talk's address problem Message-ID: <199508071909.MAA09580@puffin.pelican.com> In-Reply-To: <199508062229.XAA24522@server.netcraft.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199508062229.XAA24522@server.netcraft.co.uk> you write: >In reply to J Wunsch who said >> The correct solution would be asking the routing socket to see which >> interface address must be used to get in contact with the remote peer. >> Unfortunately, the interface to the routing socket is somewhat ugly to >> use and it requires root privileges. Hence i'm suggesting the >> following workaround. It introduces an option `-a' followed by a >> (dotted-quad) address to use for the negotiation. This address will >> be checked against the address list as returned from gethostbyname() >> to avoid abusing foreign addresses. >I want to add an option like this to everything. I'm running a multi-homed >host that has *lots* (or will have) of ip addresses and I also >need to have, for instance, a sendmail connected to each address to handle >services for that particular domain. THIS *SHOULD* be possible to use (if possible) with no mods to the client/server program source. This would eliminate the problem of needing listens on all possible interfaces like xntpd now does. >I'm gradually building such an environment but if peopl have any ideas >about this I'd be interested. As I mentioned before, the approach I'm >currently taking is to have all the servers bind to the address >returned by gethostbyname where the hostname is returned from a >modified gethostname() that looks it up in /etc/hostname. This works >for me because each of my virtual domains live in their own chrooted >environment. I'm planning to add options to bind to a command line >specified address though so the ability is more general. Boy is that not general. We need to think about incoming connections too (like the kadmind fix last week; will that work for xntpd too, and is it possible to move the fix(es) to the library and/or kernel so we don't need to go around modifying all possible clients *and* daemons? As far as I know this is only a UDP problem. -- Pete
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508071909.MAA09580>