TCPIP - Telnet sessions disconnect

[Arno van Rennes]

Using OpenVMS 7.3-2 and TCPIP V5.4 - ECO 5, TELNET sessions are disconnecting after several hours.
Another system on the same network segment, that is still on OpenVMS V7.1-2 and UCX V4.2 - ECO 5 does not have this problem.

Who knows what to do?

[Antoniov.]

Arno,
welcome to VMS forum :-)
Here you can find some other Dutch guys :-)

I have same your configuration (just upgrdated) and I work with telnet without any disconnection trouble. I hope there is no any bug for this patch.
At first glance you have to check for session limit
$ TCPIP SH SERV 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: 2 Peak: 2

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

Compare limit value with peak value.

Antonio Vigliotti

[Karl Rohwedder]

Arno,

perhaps you find a clue in accounting, why the process dies.

If a service limit is reached, a new session would be rejected, but a running session should continue.

YOu do not a have an 'idle process killer' (e.g. WATCHER) running on the node, don't you? :-)

You could also check the counters of the ethernet devices using LANCP to exclude hardware errors.

regards Kalle

[Thomas Ritter]

Firewall somewhere in the network ? Look at your keepalive values in

SYS$SPECIFIC:[TCPIP$ETC]SYSCONFIGTAB.DAT

inet:
tcp_keepcnt = 8
tcp_keepidle = 150
tcp_keepinit = 150
tcp_keepintvl = 150

Try to match them to the firewall's way of handling inactive sessions.

[Peter Quodling]

You may also want to consider setting upp virtual terminals...

q

[Thomas Ritter]

If the problem is firewall and timeouts try this command and report the results.

$ pipe sysconfig -q inet | sea sys$input keep
tcp_keepalive_default = 0
tcp_keepcnt = 8
tcp_keepidle = 150
tcp_keepinit = 150
tcp_keepintvl = 150

[Willem Grooters]

- of inactivity ? or does this hapopen regardless activity on the session )breaking off the sessions)?

[Ian Miller.]

In recent versions of TCPIP the keepalive defaults changed so use the commands as already suggested. You probably need to enable keepalive on the telnet service and change the various timeouts.

[Petr Spisek]

Hi,
"disconnecting after several hours" ... it usually looks to firewall bahaviour, but if you have another server in the same segment ... it points to problem in the certain server.
But after all try to test telnet from your console to separate the network. If problem still running, try to compare the parameters as guys advise you.
Good luck
P.

[Arno van Rennes]

Gentlemen, thanks for your reactions, I will try to answer them all at once here:

# Antonio:
$ TCPIP SH SERV 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: 200 Active: 14 Peak: 23

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

The limit values, compared to peak values looks all right to me.
The only difference with the correctly running (V7.1-2 + UCX V4.2) system = Flags: IPv6


# Kalle:
Accounting states only: Final status text: %RMS-F-RER, file read error. I have seen this before only now it happens more often.

New sessions are not rejected only running (idle) sessions are disconnected.

This system is the original of the mentioned V7.1-2 system. (e.g. the same processes are running)

The LANCP device counters look alright.


# Thomas Ritter:
The only tcp setting in SYS$SPECIFIC:[TCPIP$ETC]SYSCONFIGTAB.DAT is tcp_threads=8.

$ pipe sysconfig -q inet | sea sys$input keep
Shows %SEARCH-I-NOMATCHES, no strings matched.

By the way, the TCP SESSION TIMEOUT op de Firewall is 7200 seconds. (and the other systems on the same firewall have no problems)


# Willem Grooters:
Only idle sessions are being disconnected.

# Ian Miller:
Keepalive is enabled, do you mean I have to set the tcp_keep* settings that that Thomas Ritter mentioned, in SYS$SPECIFIC:[TCPIP$ETC]SYSCONFIGTAB.DAT?

# Petr Spisek:
Good idea, I have started a telnet from the console to its system, I will wait and see tomorrow morning if it is still there.

[Ian Miller.]

Parhaps the previous command does not produce the results expected so try

$ sysconfig -q inet

and look for
tcp_keepcnt
tcp_keepidle
tcp_keepinit
tcp_keepintvl

I think these changed in recent versions of TCPIP

[Ian Miller.]

for UCX V4.2 do
$ UCX SHOW PROTOCOL TCP/PARAM

[Arno van Rennes]

The $ prompt put me on the wrong track, i did'nt notice that it was a TIPIP command.

$ pipe tcpip sysconfig -q inet | sea sys$input keep
Shows:
tcp_keepalive_default = 0
tcp_keepcnt = 8
tcp_keepidle = 14400
tcp_keepinit = 150
tcp_keepintvl = 150

The tcp_keepidle is a lot higher than in the example of Thomas but is'nt that just what I want? (I dit not set it do)

[Antoniov.]

Arno,
$ pipe sysconfig -q inet|sea sys$pipe "keep"
tcp_keepalive_default = 0
tcp_keepcnt = 8
tcp_keepidle = 14400
tcp_keepinit = 150
tcp_keepintvl = 150

produces same result of your system.
The unique difference between my system and yours is limit in service. I have 10000. I installed a new machine (no upgrade from old system), but I think this shouldn't be important.

Antonio Vigliotti

[Arno van Rennes]

Antonio,
Just to be sure, i have set the limit for the telnet service also at 10000.
Let's see what hapens....

[Ian Miller.]

tcp_keepidle is the number of halfseconds before the initial keepalive probe is sent.
So on a idle telnet link it will be 7200 seconds before anything is sent. Your firewall timeout is 7200 seconds.
I would recommend reducing tcp_keepidle

[Thomas Ritter]

Sorry I added some confusion. We execute

$ @sys$manager:tcpip$define_commands.com

to setup our popular tcpip commands.

Therefore

$ sh sym sysconfig
SYSCONFIG == "$SYS$SYSTEM:TCPIP$SYSCONFIG.EXE".

If progress is slow, experiment with some "keepalive" values.
Do we have confirmation that a firewall is part of the network topology ? What sort of a firewall ? Checkpoint ?

If so try connection using telnet behind the firewall and report the results.

IMO, dealing with Firewalls has become a necessary skill required of the VMS system administrator.

Thomas,
Melbourne Australia.

[Arno van Rennes]

Ian,

Reducing tcp_keepidle does not help.
I even tried to set the tcp_keepidle to more than 14400 (more than the setting on the firewall which is 7200 seconds) but both setting did not change the disconnecting of idle sessions.
(it is still after about 2 hours of idle time they disconnect)

I have upgraded 2 more systems to OpenVMS 7.3-2 and TCPIP V5.4 - ECO 5 and they have the same problem now. (before that, telnet sessions did not disconnect)

Arno

[Arno van Rennes]

Thomas,

Thanks, nou i can use the tcpip commands on the $-prompt!

A firewall is part of the network topology. (i understand it is an Nokia Checkpoint Firewall-1 NG)

Before, on advice of Petr Spisek, i made a telnet sesson to the system, from the consol of the system itself, (so no firewall is used) the session did not disconnect then.

But other OpenVMS systems on the same firewall do'nt disconnect the idle telnet sesions. Also i have upgraded 2 more systems to OpenVMS 7.3-2 and TCPIP V5.4 - ECO 5 and they have the same problem now. (before that, telnet sessions did not disconnect)

Arno

[Ian Miller.]

Have you tried reducing tcp_keepidle on the upgraded vms systems?

[Arno van Rennes]

Hi Ian,

Yes, i've tried tcp_keepidle at 7200 and even 600 (5 minuts) but in both cases it lasted about two hours before the idle sessin disconnected....

So it seems like the time at the firewall (7200 seconds) is used with this OpenvVMS/TCPIP combination and before the upgrade, it seems the firewall-setting was ignored.

Arno

[Michael Yu_3 · Accepted solution]

Hi Arno,

Have you restarted the telnet service (or disable and reenable) for it to take the new tcp defaults?

If you do not want to modify the tcp defaults for all tcp connections, you can use the following tcpip command.

TCPIP> set serv telnet/proto=tcp=probe=600
TCPIP> set serv telnet/proto=tcp=drop=10
TCPIP> disable service telnet
TCPIP> enable service telnet

Remember disabling service telnet will destroy all existing telnet connections.

The following will appear in the tcpip show service telnet/full.


TCP options: Delay
Drop_count: 5 Probe_timer: 600


Thanks and regards.

Michael

[Antoniov.]

Arno,
because we are thinking to firewall and keepalive features, may be interesting show these values on your system by
$ @SYS$STARTUP:TCPIP$DEFINE_COMMANDS
$ ifconfig -p tcp
...
0 connections dropped by rexmit timeout
0 persist timeouts
0 keepalive timeouts
0 keepalive probes sent
0 connections dropped by keepalive

Antonio Vigliotti

[Arno van Rennes]

Hurray!!!! Michael, many thanks!

This did the trick:
$ tcpip set service telnet/proto=tcp=probe=600
$ tcpip set service telnet/proto=tcp=drop=10
And after disable and enable of the telnet service, the problem was over.
On all 3 upgraded systems, the idle sessions are no longer disconnected!

I still have to find out what Drop_count: 10 and Probe_timer: 600 really means, but for now I am glad the problem is solved.

* All guys, thanks for your input and Michael, thanks for the solution!
(I'll assign points in a little while)

Regards,
Arno

[Michael Yu_3]

Hi Arno,

Glad to know that the suggestion helps.

probe_count is the number of seconds between probes for idle connections.

If there is no reply from the remote, then the probe will be retransmitted according to normal TCP retransmissions, up to a total of drop_count seconds and the connection will be closed.

Thanks and regards.

Michael