Telnet Login Problem-VMS 8.3

[Jerry Rieman]

Ran into a telnet login problem last night that I had never seen before. Perhaps someone can suggest where to look. I suspect it may be related to a terminal naming problem as it looks like the TNA numbers rolled over to 10,000 when it happened.

Symptom -
Telnet users hit the system but do not get Username prompt

Decnet users can login

LAT users can login

Outgoing telnet sessions work ok

Security log shows the following message -

Auditable event: Detached process login failure
Event time: 29-MAR-2007 19:17:30.94
PID: 000190F9
Process name: _TNA10000:
Username:
Process owner: [1,4]
Image name: DSA0:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
Posix UID: -2
Posix GID: -2 (%XFFFFFFFE)
Status: %RMS-F-CHN, assign channel system service request failed


I stopped and started telnet service - no luck.

Telnet service is set for Limit=500 - would not have hit that limit.

1 then stopped and started all tcp/ip servicss - that is when system crashed. As mentioned, the rolling over to a 10,000 TNA number seems more than coincidental. Is there a setting on this somewhere? Thanks for any help.

[Galen Tackett]

Jerry,

My VMS V8.3 system is down for a while so I can't for certain if this would be a factor, but perhaps the TCPIP$INETACP process has used up its FILLM quota, which limits the number of open channels ("files").

Try this:

$ ANA/SYS
$ SET PROC TCPIP$INETACP
SDA> SHOW PROC/PHD
!
! Note the number shown for "File limit:"
!
SDA> SHOW PROC/CHAN
!
! Note the number of channels open, shown at the end of the listing of
! channels.)

SDA>EXIT

This should settle whether FILLM is the limiting factor.

On my VMS V7.3-2 system, this process when sitting idle appears to be using 24 of its current FILLM of 250. I'm not sure where that number 250 came from, without a little looking...

[Jerry Rieman]

Thanks Galen-

show proc/phd - file limit - 256

show proc/chn - 25

Of course, this is after the system has only been up for 20 hours. Until my crash last night, the system had been up for about 90 days.

My gut keeps telling me that the "TNA10000" shown in the security log is significant - but not sure how. I have been through all my logs - accounting (which has everything enabled including image accounting), security (anal/audit), and operator - no anomolies until the event noted above.

[Hoff · Accepted solution]

That looks like the roll-over sequence for big BG unit numbers.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1074590

[Jerry Rieman]

Hoff-

That has to be it! Sorry for repeating a known problem but all my ITRC searches for similar problems came up empty. The sysgen help says SCSI devices but I am willing to bet a couple of beers that it is controlling the tna assignment as well. Probably was added in tcp/ip 5.6. It is not a dynamic param so looks like a reboot is in order to pick up the new value.

Many thanks to both of you for taking the time to help. Hoff, you have been properly repped.

[atul sardana]

dear jerry,

if you set telnet limit in thousands i think your problem will be solve by it,

as per my system i had set that limit to 10,000.
As example for you can check other settings as below ....

SYSTEM>>ucx sho service telnet/full

Service: TELNET
State: Enabled
Port: 23 Protocol: TCP Address: 0.0.0.0
Inactivity: 1 User_name: not defined Process: not defined
Limit: 10000 Active: 202 Peak: 285

File: not defined
Flags: Listen Rtty IPv6

Socket Opts: Keepalive Rcheck Scheck
Receive: 3000 Send: 3000

Log Opts: Actv Dactv Conn Error Logi Logo Mdfy Rjct
File: not defined

Security
Reject msg: not defined
Accept host: 0.0.0.0
Accept netw: 0.0.0.0

I hope its useful for you..
Thanks
Atul

[Jerry Rieman]

Atul,

If I am not mistaken, the "Limit" value refers to the number of concurrent sessions - not the max TNA number. My system "Limit" is set to 500 so I do not think that is the parameter that was giving me all the heartburn. I am going to try setting the "Device_Naming" sysgen param to 4. Of course, it will take a while until I know if that does the job. Thanks.

[Volker Halle]

Jerry,

this is a known problem with TCPIP V5.6 - I've also seen it on an OpenVMS I64 V8.3 cluster as the TNA unit numbers exceeded 9999. The workaround is to set DEVICE_NAMING = 4, thereby limiting all devices to 4-digitl unit numbers. This workaround does work successfully.

The problem has been escalated as QXCM1000379192

Volker.

[Troodon]

I have systems which have experienced this and others which don't. There must be something more subtle at hand,,,

Device Device Error
Name Status Count
TNA0: Online 0
TNA24740: Online 0
TNA24776: Online 0
TNA24841: Online 0
TNA24911: Online 0
TNA24915: Online 0

I sure hope this system does not hang this week....

[STEPHEN CONWAY_1]

Mr Volker is correct. This problem (which is not technically a TCP/IP problem - it's not our fault that the assign fails - but I digress) will be remedied in the upcomming version V5.6-ECO1 release. It was never a problem in either the V5.4 or V5.5 releases.
There is a patched version of V5.6 TNdriver.
By the way, you must have a six character node name to experience this problem.

Also - In OpenVMS version 8.3 there will be some additions to the sysgen parameter "DEVICE_NAMING" to allow for different unit number maximum values.

Steve