From owner-freebsd-current Mon Aug 7 00:14:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id AAA21278 for current-outgoing; Mon, 7 Aug 1995 00:14:04 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id AAA21255 for ; Mon, 7 Aug 1995 00:13:57 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id AAA00579; Mon, 7 Aug 1995 00:13:35 -0700 From: "Rodney W. Grimes" Message-Id: <199508070713.AAA00579@gndrsh.aac.dev.com> Subject: Re: workaround for talk's address problem To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 7 Aug 1995 00:13:34 -0700 (PDT) Cc: freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de In-Reply-To: <18450.807740189@time.cdrom.com> from "Jordan K. Hubbard" at Aug 6, 95 01:16:29 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1014 Sender: current-owner@FreeBSD.org Precedence: bulk > > > 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 > > NFS has the exact same problem, FWIW. If there's a more general > solution, we should go for it. NFS does not have such a problem, or at least I have never seen it, and I have _lots_ of networks, all but 1 serving NFS: gndrsh# nslookup gndrsh.aac.dev.com Server: gndrsh.aac.dev.com Address: 0.0.0.0 Name: gndrsh.aac.dev.com Addresses: 198.145.92.49, 198.145.92.241, 198.145.92.17, 198.145.92.33 mountd gets confused if you add an interface and don't restart it, but other than that and routing path problems it works just fine. It does not have the problem that was described about talk, NFS handles this stuff just fine! -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD