topic Re: telnet session in Operating System - HP-UX

telnet session

Linda Lux — Fri, 07 May 2004 10:34:26 GMT

I installed patch PHSS_30668. Would this have an affect on opening telent sessions and getting the login screen, possibly delaying anywhere from 6 seconds to a minute for the login prompt to appear?

Re: telnet session

Bharat Katkar — Fri, 07 May 2004 10:38:55 GMT

This could be an indication of increased load on network. Network seems to be over burdened. See if you can check this first.

Re: telnet session

Linda Lux — Fri, 07 May 2004 10:42:46 GMT

I am having that side researched, too. Common thread is a change on the network, but also the installation of this patch.
And not all users are having this problem.

Re: telnet session

RAC_1 — Fri, 07 May 2004 10:44:38 GMT

What is this patch? CDE Runtime patch It should not affect telnet etc.

How you have configured name service? IS there any problem with that?

And as told by Ameet, how id the nework load?
glance -l

Anil

Re: telnet session

Linda Lux — Fri, 07 May 2004 10:49:37 GMT

what should I look for on the
glance -l

screen for the lan that all of this activity is on

Re: telnet session

Bharat Katkar — Fri, 07 May 2004 10:52:17 GMT

It would be better if you can run graphical interface of glance:

#gpm

Click on the network icon and watch the Bar for Incoming/Outgoing traffice, any transmission error, collisons etc. You will come know once you have a look at it.

All the best

Re: telnet session

A. Clay Stephenson — Fri, 07 May 2004 11:12:36 GMT

I would not expect this patch to have that problem. This sounds more like a hostname lookup problem. That is rather easy to determine. telnet ip_address rather than telnet hostname. If the telnet using the ip address is consistantly fast (or at least what you perceive as normal) then you need to look at hostname resolution. The other thing that could cause this is a mismatched speed-duplex setting between a host and its corresponding switch port. Even with mismatched duplex settings, telnet sessions will appear to work almost normally because of the low bandwidth requirement whereas an FTP session will almost instantly indicate a problem during a file transfer.

Re: telnet session

Mel Burslan — Fri, 07 May 2004 11:30:33 GMT

as far as I understand from your second post, there was a change made to your network at about the same time you applied this patch. If this is right, I would talk to the network administrators to see if there is any change in the wiring between your servers and the DNS servers. Usually a minute or longer delays in getting the login prompt, indicates a DNS lookup issue more than anything else.

If you have a luxury of sweettalking the network admins to put up a sniffer on the segment your server/lan port is located, you can get a snapshot of the network traffic at the moment you initiate the telnet command. With the sniffer they can filter packets between your telnet client wkstn and the lan interface to trace if there is any corruption or problem of any sort. But my feeling, this is highly unlikely.

If I were you, I would do a few nslookup queries both by hostname and ip address, both ways and see if you are getting instantaneous responses as you should. If not, this should tell you where to look for.

And as a last resort, if you or someone other people are really concerned that, the patch PHSS_30668 caused this fluke, you should be able to back out of it, as I think, you have applied it very recently. The backout filesets should still be present unless you deliberately removed them right afterwards.

Hope this helps

Re: telnet session

Sanjay_6 — Fri, 07 May 2004 11:36:33 GMT

Hi,

Looks more likely to be a DNS resolution problem. The system is probably trying to do a reverse lookup on the ip address from which the telnet session is coming and in unable to resolve it.

To test, Add the ip address of the workstation in your /etc/hosts file and then do a telnet and see if it is faster.

Hope this helps.

Regds

Re: telnet session

Linda Lux — Fri, 07 May 2004 11:57:28 GMT

I put the address of 2 machines in my hosts file, and the session open up to the login immediately.
What do I ask my dns/net admin people?

my /etc/nsswitch.conf file reads

files hosts[NOTFOUND=continue] dns

is that correct?

Linda

Re: telnet session

A. Clay Stephenson — Fri, 07 May 2004 12:09:08 GMT

Just as I suspected, you have a hostname resolution problem. Your /etc/nsswitch.conf file must be set to look in FILES first and then look in DNS and/or NIS. Let your network admins know what you did and let them know what happens in your hostname resolution scheme (ie what happens when the host in not found in /etc/hosts, specifically that you then look in DNS) and they should be able to resolv this. My best guess is they have a DNS master or slave server that is down.

Re: telnet session

Linda Lux — Fri, 07 May 2004 12:36:54 GMT

I had an error in my previous reply

my /etc/nsswitch.conf

is

hosts: files[NOTFOUND=continue] DNS

Linda

Re: telnet session

A. Clay Stephenson — Fri, 07 May 2004 12:40:14 GMT

Then you definitely have a problem with a DNS server; tell your Network Mr. Goodwrenches what you have found and they should be able to fix the DNS server or entries.

Re: telnet session

RAC_1 — Fri, 07 May 2004 12:42:06 GMT

That explains the cause of delay.

Before you added the ip address entries to /etc/hosts, it was going to dns for resolution and was taking time there. You can ask your network administrator about it.
May be they are overloaded.

After adding entries to /etc/hosts, the resolution was being done from /etc/hosts and was much faster.

Anil

Re: telnet session

Linda Lux — Fri, 07 May 2004 14:08:49 GMT

Okay
Net people are telling ne there is nothing wrong with DNS/WINS.

they asked if i had reverse lookup on HP?

Linda

Re: telnet session

Mel Burslan — Fri, 07 May 2004 16:59:00 GMT

could you please post the contents of your /etc/nsswitch.conf file ?

also make sure all the nameservers in your /etc/resolv.conf are 'ping'able from your host and there is no major delays, i.e., nothing more than what you see pinging other servers.

but nsswitch.conf may be the culprit

Re: telnet session

Mel Burslan — Fri, 07 May 2004 17:04:53 GMT

oops sorry.. I scrolled down too fast. I saw your nsswitch.conf file

try modifying it like this :

hosts: files [NOTFOUND=continue TRYAGAIN=continue UNAVAIL=continue] dns [NOTFOUND=continue TRYAGAIN=continue UNAVAIL=return FOUND=return]

I do not know why but dns sometimes becomes too finnecky about seeing all the options. Not everywhere but on some servers, I have seen this helping. I am not sure if yours going to be one of those but it won't hurt anything.

Hope this helps

Re: telnet session

A. Clay Stephenson — Fri, 07 May 2004 17:38:36 GMT

Do an nslookup on one of the "bad" hosts with the corresponding entry in /etc/hosts and then remove the entry from /etc/hosts and repeat with your Network guys present. If that fails, it has to be DNS. It could be that your /etc/resolv.conf has problems either in your domain or search settings. This would manifest itself, for example, if fully specified hostnames worked but the short names fail.

Re: telnet session

Linda Lux — Mon, 10 May 2004 11:21:05 GMT

this is what I am getting when I run
nslookup on one of the bad machines

# nslookup 192.168.10.172
*** Can't find server name for address 192.168.1.5: No response from server
*** Can't find server name for address 192.168.1.44: Non-existent domain
*** Can't find server name for address 192.168.1.30: No response from server
*** Default servers are not available
Using /etc/hosts on: K460

looking up FILES
Trying DNS
*** can't find 192.168.10.172: No response from server

Linda

Re: telnet session

Mel Burslan — Mon, 10 May 2004 11:31:40 GMT

Looks like there are connectivity problems with dns server 192.168.1.5. Did you check if it is pinging properly from your server?

192.168.1.44 --> this server, I think assumes a wrong network suffix for the server that you are inquiring about

192.168.1.30: --> this server is not responding for soem reason I am not sure.

In the light of the whole information in this thread, I think when you contact your DNS admins, when they told you DNS is in good shape, they meant 192.168.1.5 was in good shape. But you seem to have connectivity issues with it. And the other two are having problems, resolving addresses, really but DNS admins most probably never bothered to check these as they are secondary and teriary server.

I think relaying this infor in your last post to your DNS admins may result in a fix on their end, but at the same time, you can investigate why you cannot access the primary DNS server.