telnet session

[Linda Lux]

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?

[Bharat Katkar]

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

[Linda Lux]

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.

[RAC_1]

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

[Linda Lux]

what should I look for on the
glance -l

screen for the lan that all of this activity is on

[Bharat Katkar]

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

[A. Clay Stephenson]

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.

[Mel Burslan]

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

[Sanjay_6]

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

[Linda Lux]

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

[A. Clay Stephenson]

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.

[Linda Lux]

I had an error in my previous reply

my /etc/nsswitch.conf


is

hosts: files[NOTFOUND=continue] DNS


Linda

[A. Clay Stephenson]

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.

[RAC_1]

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

[Linda Lux]

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

they asked if i had reverse lookup on HP?

Linda

[Mel Burslan]

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

[Mel Burslan]

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

[A. Clay Stephenson]

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.

[Linda Lux]

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

[Mel Burslan]

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.

[Linda Lux]

192.168.1.5 is my K460
192.168.1.44 is the DNS server
192.168.1.30 is a Fax server

Linda

[Sanjay_6]

Hi,

Try this link on how to configure your /etc/resolv.conf and /etc/nsswitch.conf.

http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90147/B2355-90147_top.html&con=/hpux/onlinedocs/B2355-90147/00/00/9-con.html&toc=/hpux/onlinedocs/B2355-90147/00/00/9-toc.html&searchterms=nsswitch.conf&queryid=20040510-115119

http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90147/B2355-90147_top.html&con=/hpux/onlinedocs/B2355-90147/00/00/28-con.html&toc=/hpux/onlinedocs/B2355-90147/00/00/28-toc.html&searchterms=resolv.conf&queryid=20040510-115143

Hope this helps.

Regds

[Mel Burslan]

unless your K460 have another job of being a DNS server, the lines

nameserver 192.168.1.5

should not be in your /etc/resolv.conf file

same is valid for your fax server. unless it is a DNS server at the same time, it should not be listed as a nameserver.

whereas, 192.168.1.44 , i.e. the DNS server, is having a problem interpreting the input coming from your K460. After removing the unnecessary entries in your /etc/resolv.conf, if it still gives you the same response, you need to contact the DNS administrator and try to solve the problem together, because it definitely is related to their server as much as to your K460 after this moment.

make sure you have the correct domain(s) listed in this file, i.e., something like the line :

domain yourcompany.com subdomain.yourcompany.com

[Linda Lux]

I have made the DNS techie made, insisting this is a DNS issue, so I need any other thoughts, suggestions, etc on what to look for on the HP side.
Still need help!
Linda

[Mel Burslan]

is your /etc/resolv.conf file looking something like :

domain yourcompany.com
nameserver 192.168.1.44

now ? i.e., the unnecessary and wrong nameserver entries has been eliminated. Right ?

and you can ping 192.168.1.44

so far so good.

run command

# nslookup (all by itself)

at this point what do you see as output ? before ">" prompt ?