From owner-freebsd-hackers Wed Sep 13 15:04:34 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA28240 for hackers-outgoing; Wed, 13 Sep 1995 15:04:34 -0700 Received: from covina.lightside.com (covina.lightside.com [198.81.209.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA28233 for ; Wed, 13 Sep 1995 15:04:32 -0700 Received: by covina.lightside.com (Smail3.1.28.1 #6) id m0sszuu-0009Y1C; Wed, 13 Sep 95 15:04 PDT Date: Wed, 13 Sep 1995 15:04:28 -0700 (PDT) From: Jake Hamby To: Piero Serini cc: "FreeBSD Hackers' List" Subject: Re: 'talk' doesn't work! Did it ever? In-Reply-To: <199509132124.XAA00499@strider.ibenet.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hackers-owner@FreeBSD.ORG Precedence: bulk On Wed, 13 Sep 1995, Piero Serini wrote: > Hello. > > Quoting from Jake Hamby (Wed Sep 13 22:52:26 1995): > > Yeah, I was trying to talk to a SunOS box (and a Solaris box) as test > > cases. The problem is that there is an ntalk daemon in /etc/inetd.conf > ... > > Oh, and sorry for posting to hackers when I should've posted to > > questions... But, since the FreeBSD->Sun compatibility problem hasn't > > been solved yet, perhaps this is a -hackers problem after all! > > Sorry. I didn't mean to bite. > > What I understood from your original message was that talk didn't > work for you, *ever*. This has been asked many times in the past, > and solved by proper network configuration. That's why I wrote it > belonged to -questions. > > If the problem (as is) is a compatibility issue, yes, that's for > hackers. > No problem. Actually it does appear to be a compatibility issue, and I'm not sure how FreeBSD should resolve it. It appears that some of the most popular OS's (Solaris and SunOS in particular) only support the old talk daemon, which doesn't come with FreeBSD. Running 'ytalk' on FreeBSD will connect with these OS's, but the catch is that the person you're paging has to use ytalk on THEIR end or THEY get a [Checking for invitation on caller's machine] message too! It looks like Linux has an in.ntalkd which supports both protocols (at any rate, it's running on both ports 517 and 518). Is there any possibility to throw in in.talkd for backwards compatibility or patch in.ntalkd? Or just leave the situation the way it is and warn people in the FAQ? ---Jake Hamby jehamby@lightside.com