12-26-2011 03:38 AM
We are receiving the below audit alarms on OPCOM every few seconds which is filling up our system disk space.
Actually, telnet is trying to disconnect the device which is not available on the server. For example the below device TNA432 is not available on the server but for almost a week we are receiving the below message.
Its not only for one sing device, there are number of devides like this on the server.
Please let me know if you need more input on this.
OS version - 7.3-2
Tcpip Version - V5.4 - ECO 7
H/w - ES45
%%%%%%%%%%% OPCOM 26-DEC-2011 11:22:16.63 %%%%%%%%%%% (from node XXXX at 26-DEC-2011 11:22:16.67)
Message from user TCPIP TELNET on XXXX
Session TNA432: disconnected per login timeout period
Solved! Go to Solution.
12-26-2011 04:39 AM - edited 12-26-2011 05:17 AM
This problem has been reported before:
but without a solution.
What does TCPIP SHOW SERVICE/FULL TELNET show ?
Incoming TELNET devices should be shown by TCPIP SHOW DEV/PORT=23
12-26-2011 05:28 AM
Thanks for your reply.
Here is the telnet configuration:
TCPIP SHOW SERVICE/FULL TELNET
Port: 23 Protocol: TCP Address: 0.0.0.0
Inactivity: 0 User_name: not defined Process: not defined
Limit: 2500 Active: 158 Peak: 377
File: not defined
Flags: Listen Rtty IPv6
Socket Opts: Keepalive Rcheck Scheck
Receive: 3000 Send: 3000
Log Opts: Addr
File: not defined
Reject msg: not defined
Accept host: 0.0.0.0
Accept netw: 0.0.0.0
12-26-2011 05:37 AM - edited 12-26-2011 05:38 AM
TELNET> SHOW DEV/FULL TNA432: show ?
or were you saying that this device TNA432: does not exist (anymore) in your OpenVMS system ?
12-26-2011 05:52 AM
Forums? Waste of time for this and similar cases. Escalate this error to HP Support.
Switch to ssh. Telnet has massive security problems, in general. Given you're (still) using VMS, you probably also (still) using Microsoft Windows, so here is how to set up PuTTY on Windows for ssh with OpenVMS.
12-26-2011 06:51 AM
sorry, I was checking on a different node on cluster. The device actually exist.
here is the output:
SHOW DEV/FULL TNA432:
Access port name: "0.0t: 118.104.22.168 Port: 44901" !!! Changed IP as it was public and opened)
Connection attempts: 0 (tries)
Connection interval: 0 (seconds)
Connection timeout: 0 (seconds)
Data high limit: 512 (bytes at VCI port)
Data low limit: 256 (bytes at VCI port)
Idle interval: 0 (seconds)
Idle timeout: 0 (seconds)
Network device name: (not connected)
Local address: (not available)
Remote address: (not available)
Service type: None
SHOW DEV/FULL TNA432:
Terminal TNA432:, device type unknown, is offline, device set /NOAVAILABLE,
record-oriented device, carriage control.
Error count 0 Operations completed 1
Owner process "" Owner UIC [SYSTEM, SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 0 Default buffer size 80
12-26-2011 07:25 AM
When you call HP support, you can ask the HP support folks for workarounds.
I have already presented one workaround. Shut down telnet. Use ssh. You can use certificates for your logins, and either no passwords required, or passphrase-based logins. ssh doesn't expose all of the usernames and passwords in cleartext to anyone monitoring the network. Unlike telnet. And if you shut off the telnet stuff, you shut off the chatter, of course.) (There's a really nasty telnet security bug loose in the wild right now, too.)
Or shut off the OPCOM traffic from your operator terminals. See the REPLY /DISABLE sequence in the OpenVMS FAQ. This won't fix the underlying problem, but it'll hide it. It's typical to disable the OPCOM chatter on the OPA0: console terminal, which means all this character chunder lands in the OPERATOR.LOG without bothering anyone.
Or replace the TCP/IP Services stack with a Process software stack.
Or, well, ignore the chatter.
12-26-2011 09:35 AM - edited 12-26-2011 09:38 AM
As a quick workaround for disabling these messages from filling your OPERATOR.LOG, you might try a REPLY/LOG/DISABLE=(CENTRAL,NETWORK). That should stop these TELNET OPCOM messages from getting into OPERATOR.LOG
As you now know the remote IP address (and remote port), you may be able to find out, what might have caused those messages to start. Find out from OPERATOR.LOG, when those messages started and try to use ACCOUNTING and/or ANALYZE/AUDIT to get an idea, what might have caused them.
The 'real problem' is most likely in TCPIP$INETACP (some error during an incoming TELNET session and some kind of login error [network login limit exceeded ?] causing an OPCOM message to be generated in some kind of loop). A reboot should cure the problem for now, but does not 'solve' it for the future, make sure to raise a call with HP.