Funny, the exact same thing just happened to one of my servers today. Nearly same symptoms, nearly same setup. I'm running wu-ftpd (small ftp site, internal only use), RH7.2, and updated the kernel today, but before I even rebooted into the new kernel (2.4.9-31), all windows-based ftp logins were all timing out. I opened up an external route, and was able to login externally just fine.
My /etc/resolv.conf uses internal M$ DNS servers, (not maintained by me), that I know specifically do not have reverse dns setup. In fact, they never have, and the current admin thinks it's stupid to use reverse dns. But, forward dns works (all windows clients have registered hostnames, and they are the ones ftping in). I know what you're thinking, but what I'd like to know, is why it is that for 4 or so months, internal ftp access was INSTANT, as was ssh. But, starting today (I was assuming it was the kernel upgrade), ssh and ftp are dog slow. The only way I was able to ftp from windows clients, was to add an entry to the hosts file. Note: nothing has changed on the M$ side affecting dns. I did a little digging, and found this option for wu-ftpd in the man page: dns resolveroptions -recurse I put that in my /etc/ftpaccess, and windows clients were able to ftp, though after 10 seconds or so (not near as instant as before). This definitely has to do with reverse dns. I rearranged my nsswitch.conf, to no affect. Rebooted into the new kernel, but everything was still the same. What gets me is that ssh is still slow. This is a desc I found of why wu-ftpd used reverse dns: http://www.landfield.com/wu-ftpd/mail-archive/wuftpd-doc/2001/Sep/0000.h tml I was just about to setup an internal dns server and populate the zone files with host1, host2... entries, but with over 14 class c networks all on an internal network, this doesn't seem viable. What really gets me is that there IS dns zone files, with the correct info (I can do a `host windozebox` and get an immediate return from M$ dns server, but the reverse of course does not work). I considered copying those zone files, and running my own reverse dns, but is it really worth it? Anyone else have any suggestions? I seriously doubt a hack, as I run netfilter on this box, only allowing ftp, ssh, and web, though all internally only, not to mention tripwire, pix, ids, and various other things keeping baddies away. relevant configs: /etc/resolv.conf search our.domain nameserver ip.of.m$.ds nameserver ip.of.m$.dns2 /etc/nsswitch.conf hosts: files dns [NOTFOUND=return] /etc/hosts 127.0.0.1 localhost my.int.box.ip servername Thanks in advance, Vinny On Thu, 2002-02-28 at 11:17, Paul Hamm wrote: > Sounds like you have a resolver issue. Check your DNS specificaly the > reverse lookup. Or you may have been hacked ;-) > > -----Original Message----- > From: gabriel [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 28, 2002 12:41 PM > To: [EMAIL PROTECTED] > Subject: spontaneous lag (x3) > > > the oddest thing has been happening to the machines here in my office > for the past few months. most of the time, telnetd/sshd/ftpd all seem > to be working fine, but on three separate days in the last two months, > an odd lag has manifested itself during the login. ie. it takes > nearly a full minute to telnet into a local rh6.2 machine. and about > the same time to ftp between either machines. apache however, which snip _______________________________________________ Redhat-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list