This document contains details and solutions regarding message TCP2617.
Resolving The Problem
This document provides information on resolving message TCP2617 errors. These errors typically occur in the QSYSOPR message queue and in the QTCPIP joblog when a connection to a remote host was abnormally closed.
Message ID . . . . . . . . . : TCP2617
Message file . . . . . . . . : QTCPMSG
Library . . . . . . . . . : QSYS
Message . . . . : TCP/IP connection to remote system &2 closed, reason code
Cause . . . . . : The TCP/IP connection to remote system &2 has been closed.
The connection was closed for reason code &5. Full connection details for
the closed connection include:
- local IP address is &1
- local port is &3
- remote IP address is &2
- remote port is &4
Reason codes and their meanings follow:
1 = TCP connection closed due to expiration of 10 minute Close Wait timer.
2 = TCP connection closed due to R2 retry threshold being run.
3 = TCP connection closed due to keepalive timeout.
If TCPCNNMSG(*THRESHOLD) is defined for the Change TCP/IP Attributes (CHGTCPA)
command then there could be additional connections that have closed within
the threshold window. The number of additional TCP connections that have
closed is &6.
Recovery . . . : Informational message.
This is caused when the IBM System i products closes the connection to a remote host for the following reasons:
|Reason Code 1:||This text is incorrect. See APAR SE09625. This is the FINWAIT2 timer, not the CLOSEWAIT timer. The System i has received a TCP acknowledgement of our close connection request. We are waiting for the other end to send us a FIN. If we do not receive a FIN from the remote system within 10 minutes, we will close the connection.|
|Reason Code 2:||The retry threshold (R2) defined in CHGTCPA has been reached. TCP has retransmitted the same packet R2 times (which is normally 16). TCP has determined the connection has been lost and closes the connection.|
|Reason Code 3:||The System i has not received a keepalive response for 30 seconds. TCP closes the connection. One of the most common causes is a user who is closing his 5250 Telnet session without logging out. |
Another cause is a firewall that is not transferring keepalive packets.
To determine why a TCP keepalive is not responded to, a sniffer or Wireshark trace would need to be run at various points in the network. This would show how far the keepalive packets get, or if a response was sent back from the remote system.
Determine the remote hosts function.
|Reason Code 1:||Determine why the remote host is not closing its side of the connection.|
|Reason Code 2:||Determine why the remote host is unreachable.|
If the messages are constant and contain the same TCP/IP address over and over again, these can be caused by a WRITER trying to print to a TCP/IP printer that is down or off-line. The WRITER attempts to connect by sending SYN packets, which the remote host never responds to, and the R2 threshold is reached. Holding the WRITER will suppress the messages until the problem with the printer is resolved.
The TCP2617 message ID is elusive at times. When customers make changes to IP devices, there can be some "leftover" or "phantom" definitions for servers found in iNav under My Connections or under Management Central under ENDPOINTS that should be deleted.
|Reason Code 3:||Determine why the remote system is not sending back keepalive responses. Instruct remote Telnet users to log out connections before closing Telnet windows.|
A sniffer or Wireshark trace would need to be captured at various points in the network.
18 December 2019