From owner-freebsd-current  Mon Aug  7 09:31:00 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id JAA20819
          for current-outgoing; Mon, 7 Aug 1995 09:31:00 -0700
Received: from haywire.DIALix.COM (haywire.DIALix.COM [192.203.228.65])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id JAA20807
          for <freebsd-current@freebsd.org>; Mon, 7 Aug 1995 09:30:56 -0700
Received: (from news@localhost) by haywire.DIALix.COM (8.7.Beta.11/8.7.Beta.11/DIALix) id AAA21652 for freebsd-current@freebsd.org; Tue, 8 Aug 1995 00:30:50 +0800 (WST)
X-Authentication-Warning: haywire.DIALix.COM: news set sender to usenet-request@haywire.dialix.com using -f
Received: from GATEWAY by haywire.DIALix.COM with netnews
	for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com)
To: freebsd-current@freebsd.org
Date: 8 Aug 1995 00:30:46 +0800
From: peter@haywire.dialix.com (Peter Wemm)
Message-ID: <405f3m$l4h$1@haywire.DIALix.COM>
Organization: DIALix Services, Perth, Australia.
References: <199508061603.SAA07779@uriah.heep.sax.de>
Subject: Re: workaround for talk's address problem
Sender: current-owner@freebsd.org
Precedence: bulk

j@uriah.heep.sax.de (J Wunsch) writes:

>talk(1) has problems with multi-homed hosts.  To negotiate the
>connection with the remote peer, it uses the first address as returned
>by a call to gethostbyname().  This will cause the connection to hang
>for machines where not all interfaces are reachable from the Internet.
>This is often the case for the typical dialup user: he's got a SLIP
>interface with (e.g.) 111.222.111.33, and an ethernet interface with
>192.168.3.4.  The call to gethostbyname() will cause the name server
>to return 192.168.3.4 as the first address (since the name server
>believes this is the `most local' one), so talk will only be able to
>contact hosts inside the (not externally routed) 192.168.3 network.

>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.

>If nobody objects (or promises to implement the routing socket
>scenario), i'd going to commit this change.

Hmm. I have an idea.. sort-of..

Currently, you can "bind()" and "connect()" udp sockets..  bind
associates it with the local address, and connect associates the
remote address..

If it does not already do this, would this be a serious semantics
break if connect()ing to the remote address actually caused an
implicit bind()?

ie: connect(remote_address)
    getsockname(s, &local_addr);
    bind(s, INADDR_ANY) /* void the association */?

Or perhaps implement a special bind() 'feature' so that if you happen to
bind() an INADDR_ANY of a "connected" udp socket will actually choose
the correct local address corresponding to the remote..  or if you
bind to INADDR_NONE..  Whatever..

Of course, none of this will help if your default route points outside
on one interface, and the replies come back on another.. (one of our
network links has a peculiar load balancing arrangement where this
happens)

I suspect the easiest answer is to only use registered IP addresses,
and make sure you can do IP forwarding.. 

Cheers,
-Peter