Strange Telnet Problem

[Troy E. Miles]

morning,

I'm running HP-UX 11.00 configured with ssh and regular inet services. When I reboot the server I am unble to telnet or ftp for an hour or so. I can connect through ssh immediately.

Any ideas?

[Marco Santerre · Accepted solution]

Do you have any kind of error messages regarding inetd in your /var/adm/syslog/syslog.log ?

or what is the status of inetd startup in /etc/rc.log?

[Troy E. Miles]

No errors in inetd and none in /etc/rc.log. I've read several of the posts referring to telnet and applied necessary patches and increased ntpy, nstrpty, and nstrels to 400.

[Umapathy S]

Troy,
Is the dns working perfectly.

Does ping returns fast. Do nslookup works better?

Try logging the ftpd daemon. Add -l in /etc/inetd.conf
ftp stream tcp nowait root /usr/lbin/ftpd ftpd -lv

Check the time delay between when the line appears in /var/adm/syslog/syslog.log and the ftp client actually gets a session.

HTH,
Umapathy

[Bill Hassell]

Be sure to wait for more than 60 seconds. If you finally get a connection, the issue is easy: your DNS servers cannot find your hostname and IP address. telnet and ftp try to do a little bit of checking for incoming connections and both the name as well as the IP address are looked at. NOTE: the DNS issue is on the server side, not the side where you type telnet or ftp. If you're on a PC, get the IP address of your PC, then type:

nslookup 1.2.3.4

(where 1.2.3.4 is your PCs address) on the server. The server wil try to verify your PC's address through your current resolver. This is one of the reasons why having files, then dns in /etc/nsswitch.conf is preferred. If you can fix long delays or DNS issues by simply adding the name+IP to /etc/hosts, then your DNS folks have work to do. Note also that delays can be caused by the DNS server(s) not knowing their own name. nslookup will report this on the first couple of lines of output. Again, fixaable by putting the DNS server(s) name/IP addres in /etc/hosts. The hosts entry in /etc/nsswitch.conf should be:

hosts: files [NOTFOUND=continue UNAVAIL=continue] dns

Put only a handful of stable (production machines) systems in /etc/hosts (and of course, the server's own name, localhost and the DNS server names).

[Troy E. Miles]

I've watched the syslog and nothing appears out of the ordinary. I tested this morning and it was roughly a half hour before my telnet connection was made and logged in syslog. I get the same performance with FTP.

I've also tried telneting to the localhost and it hangs.

After the server is running for a half hour or more then everything is fine.

[Umapathy S]

Troy,
Is the system heavily loaded, so it takes this much time to get itself ready?

Did you monitor swap usage? If you have glance try running it. Try to monitor the system for the first half hour from console/webconsole.

HTH,
Umapathy

[Mark Greene_1]

How many IP addresses are assigned to the NIC? What is the content of you /etc/nsswitch.conf file? And does netstat -r return a route for both localhost and 127.0.0.1, and are the gateways correct?

mark

[Todd McDaniel_1]

I know this may be easy to overlook, but what did you do last before this problem started occuring?

also, this may not solve the problem, but may help you find it. I might stop/start the inetd daemon from the console as well, just to check from there...see if that will allow you to telnet right away.

I would also look at your startup file, under /sbin/init.d/inetd.

In addition, I would check if you are able to rlogin to it or rcp from another box.

I also would suggest looking at a telnet patch. have you patched recently?

[Troy E. Miles]

No, the server isn't heavliy loaded. It comes up fine. I can telnet out, I can ping, and I can connect through ssh.

NIC:

there is only only NIC assigned and netstat -r does return a route for localhost and 127.0.0.1. the gateways are correct.

Todd,

The problem has been present for several months. I was just made aware of it after a hardware failure, so I'm not sure.

I will try restarting the inetd and rlogin on the next reboot.

I did apply patches this morning:

PHCO_23651
PHCO_27370
PHKL_18543
PHKL_20016
PHKL_23409
PHKL_29434
PHNE_14820
PHNE_26096
PHNE_27821
PHNE_27902
PHNE_28143
PHKL_28150
PHCO_21187
PHCO_23791
PHCO_24542
PHKL_22840
PHKL_27980
PHKL_28766
PHNE_26771

[Ron Kinner]

Does

netstat -an |grep 23

show it listening on TCP port 23? (Telnet)

netstat -an |grep 21

show it listening on TCP port 21? (FTP)

does

nslookup nameofaclient

come back with an IP address? Is it correct?

Does

nslookup nameofserver

work?

Ron

[Mark Greene_1]

Is the parameter for telnet and ftp in /etc/inetd.conf "wait" or "nowait"?

mark

[Sanjay_6]

Hi,

Telnet and ftp does a reverse lookup. The delay seems to be bacause of some trouble that you may be having on the system while it is trying to do a reverse lookup.

do nslookup when you are having the problem.

Hope this helps.

Regds

[Umapathy S]

Troy,
Does this get solved? I am eager to know the solution.
Can you please post a summary.
cheers
Umapathy

[Mark Greene_1]

Bumping to the top of the list. This one was fairly unique; I'm sure I'm not the only person curious if this is still a problem or if it has been fixed.

mark

[Troy E. Miles]

apologies for not keeping up to date.

I'm still trying to correct problem. Haven't been able to reboot server. I've tried all the suggestions except for Reverse DNS solution. Unfortunately, none of the others worked. I'll be rebooting server tomorrow AM and will test Reverse DNS.

thanks for all the assitance,

Troy

[Mark Greene_1]

No apology necessary, particularly if you are still dealing with the problem! Thanks for the update though. This is a real head-scratcher. You'd think if this was a reverse look-up problem that it would be binary; i.e., it would always work, or it would always not. But then DNS is a strange animal.

mark

[Bill Hassell]

You can solve reverse DNS without a reboot. Simply change nsswitch.conf to have this line:

hosts: files [NOTFOUND=continue UNAVAIL=continue] dns

then put the hostnames+IPaddrs of the problem systems into /etc/hosts. Now nslookup (and nsquery) will demonstrate forward and reverse lookups. You'll find nsquery more useful than nslookup for these types of problems as you can test the behavior of different nsswitch.conf options on the command line.

[PVR]

run # inetd -l . and enable the connection logging. By default it is disabled

try telnet by mentioning ip addresses rather using hostname. If it works it might be name resolution issue.

[Troy E. Miles]

Bill,

I only experience problems for an hour after a reboot. Initially, I can't telnet or ftp to the localhost from the console or from exterior hosts. I can telnet/ftp from the console to other hosts in our network with no problems. I did check DNS and I can resolve hostname via IP and name.

[Bill Hassell]

Since you are getting a complete failure, you may need to do a network trace using nettl or other packet sniffers. Since you know the source and destination, it should be fairly simple to see the response that is causing the connection failure.

[James A. Donovan]

Just a couple thoughts....

1. Maybe there is something funky happening on the switch your server is connected to? If you have the opportunity, disconnect your server from the network, reboot and try telnetting to it using a cross-over cable and a laptop with a network card installed. If the hang issue still happens, then you know it's your server causing the problem.

2. Are you setting any ndd parameters on boot? Check your /etc/rc.config.d/nddconf file. If you are, what parameters are you modifying?

[Robert Cole_6]

For the record, I am having the exact same problem. I see this problem on 4 identically configured rp7410 systems, but I am running HPUX 11.11 (not HPUX 11.00. After a reboot, for about 20 minutes or so, I can't telnet or ftp into the systems, but I CAN telnet or ftp to any other system in my network (except another of these HP systems if it was just rebooted). Since all of the systems in this group are in the local hosts file (and DNS - forward and reverse - is working properly) it really looks like an "inetd" problem - the lights are on but nobody's home. Killing and restarting inetd doesn't fix the problem however. These are 4 recently installed systems that have just been patched. It appears the problem started just after the patches were applied. Funny though, the SAME patches were applied to 4 rp8400's that were set up at the same time and we don't see the problem there. Since we are still installing software, drivers, etc. (EMC, Veritas VCS, etc.) reboots are necessary and annoying. I'll check my patches and see if any are the same as Troy has applied....

[Troy E. Miles]

Robert,

See if you can connect with ssh.

[Michael Steele_2]

Robert, please start your own posting.