Re: [Cooker] talkd problems....race condition after being portscanned?
- Original Message - From: "Chmouel Boudjnah" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 13, 2001 12:11 AM Subject: Re: [Cooker] talkd problemsrace condition after being portscanned? Chmouel Boudjnah [EMAIL PROTECTED] writes: "Ryan Little" [EMAIL PROTECTED] writes: 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 opinionCan 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. ok i can reproduce should be fixed now in -6mdk. you need also the last setup to get it works.. -- MandrakeSoft Inc http://www.chmouel.org --Chmouel I've also noticed that in.ntalkd doesn't close after ending a remote talk session, it doesn't create the race condition like in.talkd, it just sits there idle though. Also...where can I find talk-0.17-6mdk? or are you saying it WILL be fixed when it comes out... Ryan
[Cooker] talkd problems....race condition after being portscanned?
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 openssh 25/tcp opensmtp 517/tcpopentalk 6000/tcp openX11 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 opinionCan 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
Re: [Cooker] talkd problems....race condition after being portscanned?
"Ryan Little" [EMAIL PROTECTED] writes: 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 opinionCan 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. ok i can reproduce should be fixed now in -6mdk. -- MandrakeSoft Inc http://www.chmouel.org --Chmouel
Re: [Cooker] talkd problems....race condition after being portscanned?
Chmouel Boudjnah [EMAIL PROTECTED] writes: "Ryan Little" [EMAIL PROTECTED] writes: 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 opinionCan 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. ok i can reproduce should be fixed now in -6mdk. you need also the last setup to get it works.. -- MandrakeSoft Inc http://www.chmouel.org --Chmouel
[Cooker] talkd....
Hello... i know... its icq time... irc time.. but... i use talk a lot... did you remember it? talk [EMAIL PROTECTED] or ytalk -x [EMAIL PROTECTED] so.. the daemon in 8-beta2 is dead... sugestions? Juan Diego
Re: [Cooker] talkd....
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 29, 2001 2:08 PM Subject: [Cooker] talkd Hello... i know... its icq time... irc time.. but... i use talk a lot... did you remember it? talk [EMAIL PROTECTED] or ytalk -x [EMAIL PROTECTED] so.. the daemon in 8-beta2 is dead... sugestions? Juan Diego Don't use in.ntalkd, use the normal talk daemon (in.talkd) ntalk was causing me all kinds of problems, and gobbling up cpu cycles...so I removed it and replaced it with the normal talkd...works fine now. Ryan
