Date: 8 Aug 1995 00:30:46 +0800 From: peter@haywire.dialix.com (Peter Wemm) To: freebsd-current@freebsd.org Subject: Re: workaround for talk's address problem Message-ID: <405f3m$l4h$1@haywire.DIALix.COM> References: <199508061603.SAA07779@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?405f3m$l4h$1>