HPUX won't allow telnet connections

[Joe Robinson_2]

My K260 running 10.20 suddenly started not allowing users to telnet to the system yesterday and has continued doing it intermittently. The user load is small (only about 70 users, and the system is approx. 70% idle while at that load) and the only hunch I have is that there are too many PTY connections. Is there one of you experts that can enlighten me on this?

Thanks in advance for sharing your knowledge,
Joe Robinson

[ian Dennison]

A real out-of-left-field solution,...

Had this problem a year ago; intermittent refusal to allow telnet access. An NT Administrator had taken the same IP Address as my HP-UX Box, and the switch/router was sending requests to the last box to send traffic out.

Share and Enjoy! Ian

[Pal Szabo_1]

Hi!

Increase the

nstr
nstrtel
nstrpty

parameters in the kernel.
sam-Kernel configuration-configurable parameters
Modify,Recompile then boot

Regards:
Paul

[Bill Hassell]

Make that:

npty
nstrpty

In 10.20, there is no nstrtel until 11.0. Double or triple the size of npty and set nstrpty to the same value. The maximum pty values (and corrsponding device files created automatically by SAM) are a hard limit to the number of simultaneous connections. Default is only 60 connections.

[harry d brown jr]

Increase the npty parameter to probably 1.5 times more than it is set for today.

Also take a look at this:
http://aa11.cjb.net/hpux_admin/2000/02/0195.html

and
http://www.uwsg.iu.edu/hp/hpux-tune.html#npty


live free or die
harry

[Ron Kinner]

do a netstat -a and see if you have a bunch of telnet connections stuck in FIN_WAIT_2. There is a bug in WinNT (and a few other OS's) TCP/IP code which causes these.

You can probably clear them if you can stop and start your telnet daemon. There is a patch for the WinNT problem but you have to ask for it, it hasn't been released yet.

Ron

[Sanjay_6]

Hi Joe,

What is the error returned when you do a telnet. If there are no errors ans it just sits there, it could be a network issue and not an issue on the server side. Are you unable to do a telnet from any place at at that time. What if you try a telnet from the system itself. Say you are logged into the system as userA, do a telnet to the same server, telnet serverA, and see if the user is able to login again.

Hope this helps.

Regds

[Joe Robinson_2]

Greetings,
I just wanted to follow up and thank everyone for their input on this; along with solving the problem (which was more users logging in than I had allowed for in the kernel, hence I increased the PTY's a bit after I benchmarked the system for evaluation later) I learned quite a few different aspects.

When the PTY limit has been reached, connections (ones here, anyway) connect and immediately disconnect, whether from a workstation or if I telnet "to myself" from the console. We're testing the use of VNC to see if it won't be a lot easier to support (rather than installing XTerm software on all my users PC's, and each session utilized another PTY port, hence my pushing over the threshhold. I identified this by simply doing who -q and checking the # of users on the system; as I suspected, I was at the max threshold as set in my kernel.

Hope this helps someone else out there in the future; I appreciate the learning opportunity afforded by the ITRC!

Regards,
Joe

[Rita C Workman]

Here's one last thought on these ptys...you mention you increased based on benchmark...

The pty parms take very very little in resources...so why not increase them enough to avoid hitting this problem. I have systems set from 400-800 on these parms since there is so little overhead. It would certainly save you having to keep such a close watch for something like this.

Just a thought,
Rita

[Joe Robinson_2]

Rita,

Thanks for that information...likely I'll hang out here a little late tonight, and modify my kernel accordingly. One thing I am curious about, however (and if anyone can recommend some good reading, I'd appreciate it) is when in VNC (or using X emulation), every terminal session started utilized another PTY port. Is this normal? Or could I configure my system to utilize the original connection rather than spawning additional ones?