HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Telnet problem

 
Alberto Vásquez
Occasional Advisor

Telnet problem

Hi,

I have an AlphaServer 1200 with OpenVMS V7.3, TCP/IP V5.3-18 (IP 192.168.53.28) and DECNET_OSI V7.3. Since yesterday we have a problem with Telnet sessions, sometimes Telnet responds quickly but some times it can take up to 2 minutes. The console shows the following message:

%%%%%%%%%%% OPCOM 25-SEP-2009 08:43:09.61 %%%%%%%%%%%
Message from user INTERnet on CAMEX3
INTERnet ACP Error Status = %SYSTEM-F-LINKABORT

If I try telnet 0 or telnet to another IP address, the same problem.

$CAMEX3> TCPIP SHOW 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: 250 Active: 20 Peak: 25

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

Some times the above command takes a long time to answer ( responds quickly).

$CAMEX3> TCPIP SHOW SERVICE TELNET/FULL
CAMEX3::_TNA661: 10:32:43 TCPIP$UCP CPU=00:00:02.23 PF=5851 IO=4190 MEM=207
CAMEX3::_TNA661: 10:34:06 TCPIP$UCP CPU=00:00:02.26 PF=5851 IO=4191 MEM=207
CAMEX3::_TNA661: 10:35:15 TCPIP$UCP CPU=00:00:02.27 PF=5851 IO=4192 MEM=207

I have not made any changes of hardware or software since last year. DECnet is working well because if I use form other node the command SET HOST CAMEX3 or DIR CAMEX3:: always
responds quickly.

The problem is only on the initial connection because after an established connections the system is working ok. Same case when I try to connect by name or by IP address.

FTP and PING is working ok.

By the way, I have two more alphas same model with same hardware and software configuration
(not cluster) connected to same segment (192.168.53.42 and 192.168.53.51) and I don't
have any problems with them.

Any ideas?
7 REPLIES
Volker Halle
Honored Contributor

Re: Telnet problem

Alberto,

check your name resolution config with TCPIP SHOW NAME. Are the DNS name servers up and working correctly ? What's the state of TCPIP$INET_ACP when telnet is 'hanging' ? LEF instead of HIB ?

Volker.
Alberto Vásquez
Occasional Advisor

Re: Telnet problem

Volker,

I checked the name resolution and is ok. DNS are up and running. The state of TCPIP$INETACP when telnet is hanging is LEF, after that the console show the message:

INTERnet ACP Error Status = %SYSTEM-F-LINKABORT

and then the state change to HIB.

Thanks for your help
Volker Halle
Honored Contributor

Re: Telnet problem

Alberto,

TCPIP$INET_ACP should normally be in HIB. If it is in a LEF state, this indicates, that it has issued some QIO, which takes unusually long to complete. This then probably is the reason for TELNET hanging and the link aborting.

The TELNET problem seems to be intermittent, so consider to check, if DNS is always working or if it also may fail intermittently. Consider to trace the IP traffic to your DNS server(s) using TCPDUMP and see if that hangs as well.

Volker.
EdgarZamora
Trusted Contributor

Re: Telnet problem

I've encountered somewhat similar problem in the past but the actual problem/solution escapes me at this time. One thought though... have you checked your routes?

TCPIP SHOW ROUTE
Steven Schweda
Honored Contributor

Re: Telnet problem

> I checked the name resolution and is ok.

So you say (and you may be right), but ...

The usual DNS problem which can cause a delay
like this occurs when the Telnet server
system tries to get the name of the client.
So, it does a (reverse) look-up of the
client's IP address. _That_ is what you need
to check. Being able to look up a name to
get its address is nice, but it's not always
enough. The server may also wish to look up
the client's address to get its name.

As usual, showing actual commands with their
actual output can be more helpful than vague
descriptions ("I checked") and
interpretations ("is ok").
Alberto Vásquez
Occasional Advisor

Re: Telnet problem

Thanks to all of you for your prompt help. This weekend I updated TCP/IP to ECO 2. At this moment all Telnet connections are woking well. I'll continue to monitor telnet connections all this day.

Alberto Vásquez
Occasional Advisor

Re: Telnet problem

Well... since last weekend telnet is working OK. Again thanks to all of you for your help.