>On Sat, Jun 26, 1999 at 06:14:19PM -0400, Michael G. Schabert wrote:
>> ntalk and talk were both already in /etc/services (517 & 518), and ntalkd
>> was in inetd.conf (/usr/libexec/ntalkd). Talk itself wasn't in
>> /etc/inetd.conf at all though.
>Well, you don't need the entry of talk in inetd:
>/usr/bin/talk is the client and /usr/libexec/ntalkd the daemon (AFAIK).
>
>Try adding "-l" and/or "-d" flags to ntalkd in inetd (manpage is talkd(8),
>I don't know why this "n") maybe they will help you to trace your problem.

The reason for the "n" is that talk and ntalk are entirely different
protocols (2 separate ports). My assumption now is that our ntalkd supports
listening on both ports. Since I had talk in my inetd.conf file, I had
previously thought that talk was a combo client/daemon for just talk and
just a client for ntalk, while ntalkd was a daemon for ntalk...i.e. talk
would listen on 517, ntalkd would listen on 518, & if a connection came up
on 518, ntalkd could pass it on to talk.

But my biggest problem here is that it's NOT the daemon that is giving the
error, it's the CLIENT. inetd.conf should actually be irrelevant. Talk
works fine in both directions on my computer, when talking with various
clients on different OSes. My friend's computer, however, only works when
_another_ computer initiates the connection. In that case, it'll tell the
user about the request, & the user can respond. So /usr/libexec/ntalkd is
doing its job just fine. The problem comes when someone tries to initiate
the connection _from_ his computer. That's when it gives the message. It
doesn't matter whether you try to talk a user also logged into his machine,
or whether you are trying to talk across the Net.

Mike
Bikers don't *DO* taglines.