Not sure who's maintaining talk and ntalk but here's an odd one for ya...
[root@littlebox /]# rpm -q talk
talk-0.17-5mdk
[root@littlebox /]# rpm -q xinetd
xinetd-2.1.8.9pre14-2mdk
After a portscan in.talkd starts running wild...here's what it looks like :
[root@littlebox /]# nmap localhost
Starting nmap V. 2.53 by [EMAIL PROTECTED] ( www.insecure.org/nmap/ )
Interesting ports on localhost(127.0.0.1):
(The 1519 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp
517/tcp open talk
6000/tcp open X11
Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
[root@littlebox /]# tail -f /var/log/messages
Apr 12 21:28:06 littlebox talkd[2991]: recvfrom: Connection reset by peer
Apr 12 21:28:06 littlebox talkd[2991]: recvfrom: bogus address family
Apr 12 21:28:07 littlebox last message repeated 2274 times
Apr 12 21:28:07 littlebox sshd[2993]: Did not receive identification string
from 127.0.0.1.
Apr 12 21:28:07 littlebox talkd[2991]: recvfrom: bogus address family
Apr 12 21:28:37 littlebox last message repeated 127843 times
basically the scan calls in.talkd from xinetd (as it should) but the talk
daemon continues to run, producing this buttload of errors and eating up 90%
of my cpu, sort of a "race condition" this is very very bad in my
opinion....Can anyone reproduce this? I'm running beta2 with a few things
moved around a bit as I've been trying to debug this, I've gotten the same
error from several mandrake versions of talkd...I'm out of ideas on this
one.
Can someone also point out to me the difference between in.ntalkd and
in.talkd? they appear to do the EXACT same thing...
Ryan
