Bug 2799 - Redhat6.0 has broken the talk subsystem!!
Redhat6.0 has broken the talk subsystem!!
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: ytalk (Show other bugs)
6.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: David Lawrence
:
: 2553 2641 2906 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-05-13 17:13 EDT by Chris Evans
Modified: 2008-05-01 11:37 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-06-24 15:41:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Evans 1999-05-13 17:13:33 EDT
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.
Comment 1 Alan Cox 1999-06-19 18:36:59 EDT
*** 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@webcon.net  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@webcon.net  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@webcon.net  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@ferret.lmh.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 :-)
Comment 2 Alan Cox 1999-06-19 18:37:59 EDT
*** 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@cybersites.com  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@redhat.com> 05/29/99 13:24 -------
Comment 3 Alan Cox 1999-06-19 18:39:59 EDT
*** 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@fog.org  05/18/99 06:03 -------
This issue has been resolved by not echoing log entries to /dev/tty9
using the /etc/syslog.conf file.
Comment 4 Alan Cox 1999-06-19 18:43:59 EDT
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 ;)
Comment 5 Jeff Johnson 1999-06-20 12:02:59 EDT
Fixed in dist-6.0.4 talk-0.11-2. Jay this needs QA ...
Comment 6 Jeff Johnson 1999-06-24 15:41:59 EDT
Fixed in talk-0.11-2.

Note You need to log in before you can comment on or make changes to this bug.