Can't Telnet when Internet connection goes away.

[Nate Arnold]

We are experiencing a problem in establishing new Telnet connections when we lose connection to the Internet. He is a synopsis of my troubleshooting steps:

1) I am though able to establish FTP, XDMCP, and rlogin connections to the server.
2) Telnet connections that are currently established continue to work but we are not able to establish any new ones. An example of all we get is the following:

rocky:/root # telnet rocky
Trying...
Connected to rocky.

I have left this connection in this state for over 5 minutes with no response.

3) As soon as the Internet problem is resolved or if I kill and restart inetd telnets begin working properly.
4) nestat -rn appears to show the appropriate routing.
5) I am not able to telnet to the local host by any hostname or ip address (there are a couple of private networks on this box) but telnets to other servers work fine.
6) I am not able to telnet to the loop back address.
7) I am not running gated or mrouted daemons
8) This server is part of a two node service guard cluster. The other node has similar routing tables and patch levels and does not experience this problem.
9) Since this problem has occurred only in the morning we have not been at full capacity during these outages. There were around 250 out of the normal 1400 connections.
10) Syslog is not capturing any clues with inetd -b turned on.

[Jeff Schussele]

Hi Nate,

I'm not quite sure what you're saying here.
Are you saying that /usr/sbin/inetd dies & you have to restart or are you saying that the telnetd daemon quits responding?

If you have trouble only when you're internet connection fails could it be possible that your DNS server resides out there? telnet will not accept connection unles it can try to resolve the source host. So when you I'net connection fails can you nslookup anything?

Rgds,
Jeff

[Nate Arnold]

I am saying that telnet quits responding to requests. If I kill inetd and restart it telnets begin working.

In terms of DNS I it looks to a local server in the same subnet. The secondary and tertiary servers are located in a data center in another subnet.

[Nate Arnold]

Sorry Jeff I forgot to answer another one of your questions. nslookups during this time appear to be working just fine.

Does HP-UX have to make a DNS call to telnet to entries located in /etc/hosts?

[Marvin Strong]

hmm so restarting inetd, even without your I'net connection it will start working?

telnet 0 work?

telnet ip work?

telnet host fails

nslookup host
nslookup ip
do those resolve?

nsswitch.conf set correctly?

does it every timeout or give connection refused?
Or does it just hang at the spot shown above?

[Nate Arnold]

Telnet 0 and telnet IP do not work.

Here is my nsswitch.conf settings:
passwd: compat
group: compat
hosts: files [NOTFOUND=continue] dns [NOTFOUND=return] files
networks: nis [NOTFOUND=return] files
protocols: nis [NOTFOUND=return] files
rpc: nis [NOTFOUND=return] files
publickey: nis [NOTFOUND=return] files
netgroup: nis [NOTFOUND=return] files
automount: files nis
aliases: files
services: nis [NOTFOUND=return] files

It just hangs at the spot shown above.

[RAC_1]

telnet
On telnet prompt
toggle options

Post the results.

when internet goes down, do you get any message in syslog file?

Also what is your ip_ire_gw_probe setting?

ndd -get /dev/tcp ip_ire_gw_probe

should be disabled.(should be 0)

Anil

[Jeff Schussele]

OK - could be patch related.

Here's the most recent telnet patch - PHNE_24829

http://www2.itrc.hp.com/service/patch/patchDetail.do?BC=patch.breadcrumb.main|patch.breadcrumb.search|&patchid=PHNE_24829&context=hpux:800:11:11

The latest Streams cumulative - PHNE_29825

http://www2.itrc.hp.com/service/patch/patchDetail.do?BC=patch.breadcrumb.main|patch.breadcrumb.search|&patchid=PHNE_29825&context=hpux:800:11:11

And a pstat_getsocket patch which could fix a "hung" telnet connectio - PHNE_29696

http://www2.itrc.hp.com/service/patch/patchDetail.do?BC=patch.breadcrumb.main|patch.breadcrumb.search|&patchid=PHKL_29696&context=hpux:800:11:11

HTH,
Jeff

[Nate Arnold]

Anil,

ndd -get /dev/tcp ip_ire_gw_probe

returns a 1 but all of my HP-UX servers do this and they don't experience any problems. They are also located in the same subnet as the server that is having problems.

[Nate Arnold]

The problem with patching is that we still have no guarantee that we have solved the problem. I would think that the other server in the cluster with the same patch kits would exibit the same problem. It is just difficult to ask for downtime on a mission critical system to "potentially" fix the problem.

[Jeff Schussele · Accepted solution]

Ok - but you definitely need more info. I think you were mistaken in bullet #10 -b is not an inetd option but rather a telnetd option & that's just for banners.
You need to up the inetd logging with
inetd -l
This does not affect current sessions - all it does is up the inetd logging.

HTH,
Jeff

[Nate Arnold]

My misktake on item #10 I had inetd set with the -l flag but we didn't see anything logged here.

Apr 23 13:51:36 rocky inetd[7052]: Connection logging disabled
Apr 23 13:51:57 rocky inetd[7052]: Connection logging enabled