telnetd problems

[Christopher McCray]

I have a new L class 2000 which is going through a first-time configuration. After the first reboot, I found that I could not telnet into the machine from any others, but could telnet to them. My machine is known by dns by both IP and hostname. I found that in one instance I could telnet into it after I first telneted out. Another instance I was able to by just waiting a long time, and still a couple of other times by bouncing inetd and changing permissions. In all instances, after a reboot to test, all initial attempts to telnet into the machine failed. I would greatly appreciate any thoughts.

Chris

[boley janowski]

i found this link for you:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0xaeffa12d6d27d5118fef0090279cd0f9,00.html

this might help, however there is also a file under /etc/ that can be set to disable telnet abilities, i can recall what it is but thougth i might mention it (as i recall the name of the file was pretty discriptive)

hope this helps.

[Bill Hassell]

Telnet requires two processes, one on the client (telnet) and one on the server (telnetd). For security, telnetd takes the name or IP of the incoming client and looks up the address. It takes about 40 seconds to time out each DNS server when it cannot ask for information. If you have 2 DNS servers listed, then 80 seconds, etc.

DNS is a very hierarchical protocol--no one server knows all addresses/hosts. DNS servers depend on other domains to answer questions about requests and rather than return 'unknown' the server asks an authority nameserver for that domain.

To verify that you have DNS problems, place the name of the client computer (hostname) and also the fully qualified name (host.domain.com or whatever) along with the IP address into /etc/hosts. Then change /etc/nsswitch.conf to file then dns. If everything works (no delays connecting with telnet, the issue is with DNS information.

It is generally recommended that file then dns be used for reliability.

[Andrew Maslin]

Chris,

The thread Boley provided a link to might have some information that will help you, as I'm going through a similar issue. After rebooting the box, try waiting awhile and see if the problem goes away and you can log in as usual. In my case, I couldn't telnet into the box at all for 17 minutes after I rebooted. Try telnetting to localhost as well (after logging in on the console) to make sure there's no problems, and see if other items (such as ftp) are working during the time that telnet access is not working.

At the end of my thread there are several suggestions that I have not yet been able to try (I can't reboot my machine very often), so you might check those out if your symptoms match mine.

[Christopher McCray]

Just to let you know, I had solved the issue with telnetd. The problem was with rcpbind being prevented from starting in the startup scripts. It has been a requirement to disable all nfs startup scripts in the rc2.d and rc3.d directories, but I have learned that this prevents telnet, ftp, CDE, and who knows what else from starting up in a timely fashion. All of my possible networking issues were fine, but as soon as I enabled the S400nfs.core file in rc2.d, I once again had insantaneous connection to my machine from others, and my CDE was instantly accessible. Thank you all for your inputs.