Hi Oh dear. in.talkd is broken. To reproduce, login on tty1 as root login on tty2 as some other user e.g. "chris" on tty1 type "ytalk chris" on tty2 you get a message. respond with "ytalk root" Both ytalks appear to connect but HANG forever. A message is logged in /var/log/messages about a "bad talk protocol version". This further exposes a ytalk bug; Ctrl-C on the failed ytalk hangs the process completely and it has to be manually kill -9'ed. Perhaps that should be logged as a separate bug The problem appears to be in.talkd. If I disable it, then in.ntalkd seems to take precedence, and works _almost_ properly. I say _almost_ properly, because when the talk session is closed, the in.ntalkd process hangs around erroneously. This is again another bug that possibly should be logged separately. I swear this all worked in 5.2. I wouldn't close this bug until all the "sub-bugs" in ntalkd and ytalk have been fixed, otherwise the report of these might get lost.
*** Bug 2553 has been marked as a duplicate of this bug. *** Problem: After upgrading from RedHat 5.2 to 6.0, I found that ytalk would allways hang and would not get any connection Solution: Uninstalling the talk package and installing the ntalk package from RedHat 5.2 cured the problem for me. No changes were needed to the ytalk package. ------- Additional Comments From rhardy 05/09/99 05:06 ------- We had the same problem. We solved the problem by doing an rpm -e ytalk, installing Redhat's SRPM, rebuilding the ytalk rpm with rpm -bb and installing the new RPM. Everything seems to work fine now. ------- Additional Comments From rhardy 05/10/99 16:24 ------- I was incorrect in my previous statement. A recompile has no effect on the hanging of ytalk. Both in.talkd and in.ntalkd seem to fight over ytalk connections. Commenting out the in.talkd line and leaving the in.ntalkd line active makes ytalk behave normally. ------- Additional Comments From rhardy 05/10/99 16:31 ------- I thought I should reword my previous incomprehensible message... When a ytalk process hangs, both a in.talkd and in.ntalk can be observed running on the destination machine. The only way we could stop ytalk from hanging was to comment out the in.talkd line in inetd.conf (leaving in.ntalkd active). ------- Additional Comments From chris.ox.ac.uk 05/14/99 09:23 ------- I logged a duplicate bug yesterday.. Note that even when you disable in.talkd, and get it working through in.ntalkd, there is still a bug. When a talk session terminates, the in.ntalkd process is left hanging around. This also needs fixing. The severity, "normal" sounds wrong to - the whole talk subsystem is knadgered which is quite serious :-)
*** Bug 2641 has been marked as a duplicate of this bug. *** I got these messages while trying to connect to someone via YTALK. They were on the local network with messages on. They couldn't connect back to me, and this was the garbage in the syslogs. I believe they were using a vanilla redhat 5.2. The logs are from my machine (vanilla redhat 6.0) ==> /var/log/messages <== May 7 16:48:33 dhcp78 talkd[6198]: dhcp78.cybersites.com (207.92.123.78): unintelligible packet ==> /var/log/secure <== May 7 16:48:33 dhcp78 in.talkd[6198]: connect from 207.92.123.78 ==> /var/log/messages <== May 7 16:48:35 dhcp78 talkd[6198]: dhcp78.cybersites.com (207.92.123.78): bad protocol version 0 May 7 16:49:10 dhcp78 last message repeated 7 times May 7 16:49:20 dhcp78 last message repeated 2 times May 7 16:49:22 dhcp78 talkd[6198]: dhcp78.cybersites.com (207.92.123.78): bad protocol version 2 May 7 16:49:43 dhcp78 last message repeated 5 times May 7 16:49:48 dhcp78 inetd[377]: /usr/sbin/tcpd: exit signal 0xb May 7 16:49:48 dhcp78 talkd[6198]: dhcp78.cybersites.com (207.92.123.78): unintelligible packet May 7 16:49:50 dhcp78 talkd[6198]: dhcp78.cybersites.com (207.92.123.78): bad protocol version 0 May 7 16:50:15 dhcp78 last message repeated 5 times May 7 16:50:19 dhcp78 talkd[6198]: dhcp78.cybersites.com (207.92.123.78): bad protocol version 2 ------- Additional Comments From gordian 05/29/99 11:55 ------- This is really an annoying problem. Can we have a status update? I just tried it on another redhat 6.0 box with the same problem. I had to kill the process because the xterm froze. TALK works, however. ------- Email Received From Jeff Johnson <jbj> 05/29/99 13:24 -------
*** Bug 2906 has been marked as a duplicate of this bug. *** After upgrade to RedHat 6.0 from RedHat 5.2, talkd reports "bad protocol version 2" errors every 5 seconds (approximately). This may have to do with the fact that the Upgrade did not change the virtual terminals from the format ttyp1 to the format pts/1. Log Excerpt: May 18 05:32:33 fog talkd[15095]: fog.org (24.112.89.163): bad protocol version 2 May 18 05:33:08 fog last message repeated 7 times May 18 05:34:13 fog last message repeated 13 times May 18 05:35:18 fog last message repeated 13 times transcript of who command: [root@fog douglask]# who root tty1 May 15 03:50 douglask ttyp0 May 18 05:30 (Courtyard) ------- Additional Comments From douglask 05/18/99 06:03 ------- This issue has been resolved by not echoing log entries to /dev/tty9 using the /etc/syslog.conf file.
Delete the bogus in.talkd line from /etc/inetd.conf killall -1 inetd killall in.talkd no messages, ytalk will work, life is good. JBJ care to either ship a true old style in.talkd or not put it in inetd.conf ;)
Fixed in dist-6.0.4 talk-0.11-2. Jay this needs QA ...
Fixed in talk-0.11-2.