talkd does not work

Ran into this problem today, to my frustration! That's at least one other user who still cares about talk/talkd.

     So, I pulled the source, commented out the sanity checks that force talkd to say "talkd[13554]: recvfrom: bogus address length". WIth this commented out it said "bogus address family". With *this* commented out, it logs lines such as "Oct 3 23:44:56 voltron talkd[15391]: ::a00:205:0:0 (0.0.0.0): unintelligible packet"

     There's the problem! That looks suspiciously like (part of) an IPV6 address -- I think it is not specifying the address type, is being given the IPv6 address, and is thoroughly not IPv6 compatible. I'm going to look into this, if not tonight then pretty soon. I'm assuming it'll be a 1-line patch to specify IPV4 only. (Well, 3 lines maybe if I patch the broken username in Bug 250971.) I think this will also fix 250975 (Ytalk hangs). Ytalk does hang, as a direct result of talkd not working.

     Yeah. inetd.conf, "udp"s should be "udp4"s or an IPV6 connection is being used I think. Also, I found when running as "nobody" (since nobody.tty doesn't work), that ytalk would return "hwertz@voltron refusing messages". Running as "root" I get a ytalk request properly. I suppose this is insecure, "nobody" should be placed into the tty group (it appears in /etc/group tty has no members whatsoever.)

I've duplicated the bug in 8.10. The only way I could get talk/ytalk to work is by making these changes - modifying inetd.conf to use udp4 and adding user nobody to group tty.

Hmm; this bug is a bit confusing; On quantal I've got ytalk(3.3.0-5) to work with talkd (0.17-15) (using openbsd-inetd)

However, while the text of the report talks about using apt-get source talkd, the package it is associated with is inetutils,
and inetutils has it's own talkd, inetutils-talkd.

I've also got inetutils-talkd (2:1.9-1) to work with ytalk using openbsd-inetd

So that sounds like both talkd's are OK.

However, if I run inetutils-talkd with inetutils-inetd (which you would think sane) it doesn't work with the log error:

Sep 27 02:44:06 major inetd[31537]: talk/tcp: getaddrinfo: Servname not supported for ai_socktype

which does sound suspiciously similar (but not quite the same as the original report - even though I'm not sure whether the original reporter really intended to report it against inetutils or talkd.

So confirming, since inetutils-inetd+inetutils-talkd doesn't work.

I run into this problem when running in.talkd daemons between Debian 8.5 and Fedora 24. I'm letting everyone know about how I could make the two work even though not one of the involved machined was an Ubuntu one, because I guess the issue other people experienced years ago could be caused by the same configuration errors.

Involved distros (lsb_release -d):
Description: Debian GNU/Linux 8.5 (jessie)
Description: Fedora release 24 (Twenty Four)

Involved packages:
(dpkg-query --search /usr/sbin/in.ntalkd)
talkd: /usr/sbin/in.ntalkd
(dpkg-query --show talkd)
talkd 0.17-15

(rpm -qf /usr/sbin/in.ntalkd)
talk-server-0.17-50.fc24.x86_64

First thing, I put the following lines in the /etc/xinetd.d/ntalk file on both machines:

service ntalk
{
        disable = no
        id = talk-dgram
        socket_type = dgram
        protocol = udp
        flags = IPv4
        #user = nobody
        user = talk
        server = /usr/sbin/in.ntalkd
        wait = yes
}

As I did not want the nobody user to be part of a system group (it's supposed to be always the least-capable user in the system), I created on both machines an ad-hoc talk user with the command:

[root@... ~]# useradd -c 'in.talkd User' -d /nonexistent -s /usr/sbin/nologin -r -g tty talk

Line "flags = IPv4" was necessary in order to prevent the two talk client to hang after displaying: [No connection yet] followed by: [Checking for invitation on caller's machine] and the following line appearing in the Fedora machine log /var/log/messages:

Jul 14 12:23:57 wrkstn07 talkd[2457]: recvfrom: bogus address length

Restricting the two talkd daemons made this error disappear. However, another error showed up that would prevent the talk session to initiate:

On the Debian machine: [Target machine does not recognize us] ... [Trying to connect to your party's talk daemon]
On the Fedora machine: [Waiting for your party to respond] ... [Trying to connect to your party's talk daemon]

On the Fedora machine I got this line in the log:

Jul 14 12:31:10 wrkstn07 talkd[2467]: 192.168.1.63: bad dns

I then added this line on the Fedora machine's /etc/hosts file:

192.168.1.63 debian

The last attempt at talking between the two machines worked:

[Connection established]

Hope others will benefit from this followup.