I have a Dual Pentium III based server and 512 Meg of ram, all running
at 400Mhz. A DPT RAID controler and a tulip 100 Base-T Either Card.
Upon inital contact with the machine the response is very slow. It may
take up to 6 minuites to get a login. But one the login is received the
system works fine. Speed is great I have no complaints. I have tried
different IRQ's for the card and different i/o settings all give the
Port 21 is next to impossible to log on to. (My FTP Server)
Port 23 is slow ............................(My telnet sessions.)
Port 80 is Damn Fast! ......................(My web Server.)
Below are not my problems but requests Please answer them if you can.
Oh and who the Hell wrote the G++ compiler! Someone send that guy a
check! That is the fastest thing on the planet! Why is he/she giving
it away and not selling it! Geez Louise!
I am also looking for a 386/486/Pentium Assembler. I have a project that
C++ just won't cut do to program size. I really need to get down and
dirty on this project. Can you help me. I am willing to pay for it.
Thankyou for your time.
Most likely it's trying to do a reverse DNS lookup
on the hostname of the connecting machine, and it's
timing out. Make sure your DNS settings are sane.
*** Bug 7442 has been marked as a duplicate of this bug. ***
------- Email Received From "Michael Velasco" <email@example.com> 12/04/99 07:16 -------
There is a real bug here too. "in.telnetd" passes "host space domain" after
the -h flag instead of "host dot domain". "login" attempts a reverse DNS
lookup on "host dot" which can take forever if there is no route to a root
DNS server, even if all your forward and reverse DNS is complete and consistent.
I was recently locked out of a remote server because of this. It had lost its
default route and, although I could start a telnet session from the border
router, the bogus reverse DNS lookup always took longer than the login timeout.
Does this problem still exist with the current release? I am unable to
duplicate this in the current version.
Problem existed in 6.1. It appears to be fixed in 6.2 (telnet-server-0.16-6).
Thank closing this bug.