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 same results. 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. Michael Velasco
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" <unixguru10> 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.