From owner-freebsd-current  Mon Aug  7 12:02:42 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id MAB25865
          for current-outgoing; Mon, 7 Aug 1995 12:02:42 -0700
Received: from pelican.com (pelican.com [134.24.4.62])
          by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id MAA25858
          for <current@freebsd.org>; Mon, 7 Aug 1995 12:02:36 -0700
Received: from puffin.pelican.com by pelican.com with smtp
	(Smail3.1.28.1 #5) id m0sfXRT-000K2lC; Mon, 7 Aug 95 12:02 WET DST
Received: (from pete@localhost) by puffin.pelican.com (8.6.11/8.6.9) id MAA08206; Mon, 7 Aug 1995 12:02:26 -0700
Date: Mon, 7 Aug 1995 12:02:26 -0700
From: Pete Carah <pete@puffin.pelican.com>
Message-Id: <199508071902.MAA08206@puffin.pelican.com>
To: current@freebsd.org
Subject: Re: workaround for talk's address problem
In-Reply-To: <405f3m$l4h$1@haywire.DIALix.COM>
References: <199508061603.SAA07779@uriah.heep.sax.de>
Sender: current-owner@freebsd.org
Precedence: bulk

In article <405f3m$l4h$1@haywire.DIALix.COM> you write:
>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

.....
This problem is more general than it looks; kadmind and kerberos daemon
both don't do listens on other interfaces than the first one.
I don't know about other udp daemons.  The suggested fix about using
the routing socket would work for these two since they run as root,
but that isn't super general.
For that matter, xntpd doesn't correctly handle interfaces that come up 
after it is started...

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

Can't be done; my (current) (sl)IP provider WILL NOT route, and won't
handle a registered internal address for me...  This is a very common
situation and will get more common with the proliferation of leaf-node
providers.  Some *fairly general* fix to udp connect/accept is needed.
TCP has no problem.

-- Pete