Contents

Configuring TCP connection trace· 1

About TCP connection trace· 1

Operating mechanism·· 1

Common reasons for TCP disconnection· 2

TCP connection trace tasks at a glance· 3

Configuring TCP connection trace rules· 3

Setting the maximum number of traced data packets per TCP connection· 4

Setting a memory quota for recording TCP connection information· 4

Enabling TCP connection trace· 5

Specifying a cache mode for TCP connection trace· 5

Enabling persistence for TCP connection trace configuration· 5

Display and maintenance commands for TCP connection trace· 6

TCP connection trace configuration examples· 6

Example: Tracing IPv4 TCP connections· 6

Example: Tracing IPv6 TCP connections· 10

Configuring TCP connection trace

About TCP connection trace

Transmission Control Protocol (TCP) is a reliable connection-oriented network communication protocol. A TCP connection is established before data transmission, and it is released after data transmission is completed. TCP connections are complicated and are more prone to abnormal terminations due to various reasons.

The TCP connection trace feature traces TCP connections on the device, records information (including packet information) about existing connections, and caches information about abnormally closed connections. The recorded information helps you locate TCP disconnection reasons.

Operating mechanism

Tracing data packets after the connection establishment

As shown in Figure 1, the TCP client and the TCP server transmit data packets after they establish a TCP connection. The TCP connection trace feature traces data packets and records the connection information. If you enable this feature on both the TCP client and the TCP server, the two devices operate as follows:

·     The TCP client records information about each sent data packet, including the send sequence number and the packet send time in the TCP header.

·     The TCP server records packet information after it receives the packet.

To display packet information, execute the related display commands.

Figure 1 Packet trace after the TCP connection establishment

 

Caching abnormally closed TCP connections

By default, the TCP connection trace feature records information only about abnormally closed TCP connections. As shown in Figure 2, the TCP connection is unexpectedly closed on the TCP server when the server fails, but the TCP client is not aware of the server failure. With an expectation of an ACK packet from the server, the client sends data packets to the server and starts the retransmission timer. When the timer expires, the TCP client continues to retransmit packets if no ACK packet is received. Without receiving any ACK packet from the server after a number of retransmission attempts, the client sends an RST packet to terminate the connection. In this case, the TCP connection trace feature on the TCP client records the information about retransmitted packets and the disconnection reason in the memory. You can execute related display commands to view the information.

Figure 2 Abnormal disconnection of TCP connection

 

The device does not record the last RST packet sent before the disconnection, but it records the disconnection reason contained in the RST packet.

Common reasons for TCP disconnection

The following are typical reasons for abnormally disconnection of TCP connections:

·     Send reset/Received reset—The device closes the TCP connection when it receives an RST packet from the peer or sends an RST packet to the peer in one of the following conditions:

¡     A TCP server sends an RST packet to a TCP client when the server receives a TCP connection request on a non-open port from the client.

¡     The device encounters an exception (for example, application crash) during TCP exchange and sends an RST packet to notify the peer to release TCP connection resources.

¡     A TCP server replies an RST packet to a TCP client when the server receives a TCP packet that does not match any existing TCP connection.

¡     A TCP client sends an RST packet to the server if the client does not receive any ACK packet after making the maximum number of retransmissions or the retransmission timeout.

For this disconnection reason, use the following methods to resolve the issue:

¡     Verify that the TCP port number is correct on the TCP client.

¡     Verify that the TCP server operates normally.

¡     Verity that the TCP-based application on the TCP client or TCP server operates correctly.

·     Application abnormal close—The TCP connection is closed when the application on one end detects abnormal packets and notifies the TCP module to send a FIN packet to the other end.

·     Keepalive timeout—After a TCP connection is established for a TCP-based application, the device detects the aliveness of the peer as follows:

¡     If the application itself supports keepalive probing, the device uses keepalive probing of the application for aliveness detection.

¡     If the application does not support keepalive probing, the device uses the keepalive probing of the TCP protocol for aliveness detection.

When the idle time of the TCP connection exceeds the TCP keepalive duration, the TCP server sends a probe packet without any data to the peer. The server determines the client's status as follows:

¡     If the server receives the ACK packet for the probe packet from the client, it determines that the TCP client is working normally.

¡     If the server does not receive any ACK packet for multiple probe packets, it determines that the application on the TCP client has been crashed and terminates the connection.

·     Persist timeout—The device closes the TCP connection if it does not receive any ACK packet from the peer within a period of time.

If the TCP server does not have any free buffer space, it sends a notification to the TCP client. Upon receiving the notification, the TCP client stops sending packets to the TCP server and starts a timer. When the timer expires, the TCP client sends a space query packet to the TCP server.

¡     If the TCP server answers that it has free space, the TCP client sends data packets to the TCP server.

¡     If the TCP server answers that it has no free space, the TCP client resets the timer, and sends the query packet again after the timer expires. The client terminates the TCP connection if it does not receive any answer from the server for a long time.

·     Retransmission timeout—The TCP client expects an ACK packet from the server after sending a data packet to the server. If the client does not receive an ACK packet in a period of time, it retransmits the data packet. If the client does not receive any ACK packet after making 12 retransmission attempts, the client terminates the TCP connection. To troubleshoot this failure, verify that the TCP server operates correctly and the link between the TCP server and client is connected.

·     Backup drop—After TCP NSR is enabled, a backup TCP connection is established on the standby MPU. When a TCP connection exception occurs on the standby MPU, the TCP connection on the standby MPU is terminated.

TCP connection trace tasks at a glance

To configure TCP connection trace, perform the following tasks:

1.     (Optional.) Configuring TCP connection trace rules

2.     (Optional.) Setting the maximum number of traced data packets per TCP connection

3.     (Optional.) Setting a memory quota for recording TCP connection information

4.     Enabling TCP connection trace

5.     (Optional.) Specifying a cache mode for TCP connection trace

6.     Enabling persistence for TCP connection trace configuration

Configuring TCP connection trace rules

About this task

You can configure TCP connection trace rules to identify TCP connections of important services for monitoring.

Restrictions and guidelines

You can configure TCP connection trace rules only when the TCP connection trace feature is not enabled.

Procedure

To configure TCP connection trace rules, execute the following command in user view:

tcp trace filter { acl acl-number | acl6 ipv6-acl-number | only-new-connection } *

By default, the feature traces all existing TCP connections.

Setting the maximum number of traced data packets per TCP connection

About this task

The device might have lots of TCP connections. If a traced TCP connection has a large number of packets, the device might not have enough memory to trace other TCP connections. To avoid this situation, set the maximum number of packets that can be traced per TCP connection.

This feature counts the number of incoming and outgoing data packets for each TCP connection. When the number of traced packets in a TCP connection exceeds the upper limit, new records of the connection overwrite its old records.

Restrictions and guidelines

You can set the maximum number of packets that can be traced per connection only when the TCP connection trace feature is not enabled. To disable TCP connection trace, execute the undo tcp trace enable command.

Procedure

To set the maximum number of data packets that can be traced per TCP connection, execute the following command in user view:

tcp trace max-packet-number packet-number

By default, the TCP connection trace feature can trace a maximum of 500 data packets per TCP connection.

Setting a memory quota for recording TCP connection information

About this task

After you enable the TCP connection trace feature, the device starts recording information about packets of specified TCP connections, including the packet sequence number and send time. If a large number of TCP connections exist on the device, it will consume a large amount of memory to record packet information, affecting the performance of other features. To avoid this situation, set a reasonable memory quota.

When the allocated memory is used up, the device does not record packet information about new TCP connections. For an existing connection, new packet records overwrite its old records.

Restrictions and guidelines

You can set the memory quota only when the TCP connection trace feature is not enabled. To disable TCP connection trace, execute the undo tcp trace enable command.

Procedure

To set the memory quota for recording TCP connection information, execute the following command in user view:

tcp trace memory-quota memory-quota

By default, a 100 MB memory is allocated for recording TCP connection information.

Enabling TCP connection trace

Restrictions and guidelines

You can enable TCP connection trace on either a TCP client or TCP server. Because a TCP server has more TCP connections than a TCP client, this feature on a TCP server consumes more memory resources than on the TCP client. If you want to trace specific TCP connections, enable this feature on the TCP client as a best practice.

Procedure

To enable TCP connection trace, execute the following command in user view:

tcp trace enable

By default, TCP connection trace is disabled.

Specifying a cache mode for TCP connection trace

About this task

By default, the TCP connection trace feature does not record information about normally closed TCP connections. To enable recording of those connections, specify the all keyword in the tcp trace cache-mode command. You can use the following commands to view related information:

·     display tcp trace cache-connection

·     display tcp trace cache-packet ip

·     display tcp trace cache-packet ipv6

Procedure

To specify a cache mode for TCP connection trace, execute the following commands in user view:

tcp trace cache-mode { abnormal-close | all }

By default, the TCP connection trace feature records information only about the abnormally closed TCP connections.

Enabling persistence for TCP connection trace configuration

About this task

By default, the TCP connection trace configuration cannot survive a device reboot. To enable the existing TCP connection trace configuration to continue taking effect after the reboot, execute both the tcp trace persist and save commands.

·     The tcp trace persist command enables the device to save the TCP connection trace configuration into the database file.

·     The save command enables the device to save the TCP connection trace configuration in the database file into the .mdb binary configuration file.

When the device reboots, the TCP connection trace configuration is automatically restored from the binary file.

Procedure

To enable persistence for TCP connection trace configuration, execute the following command in user view:

tcp trace persist

By default, persistence for the TCP connection trace configuration is disabled.

Display and maintenance commands for TCP connection trace

Execute display commands in any view and reset commands in user view.

 

Task	Command
Display information about all disconnected TCP connections that have been cached.	display tcp trace cache-connection { ip | ipv6 } slot slot-number
Display packet information about a disconnected IPv4 TCP connection that is traced.	display tcp trace cache-packet ip source-ip source-ipv4-address source-port source-port-number destination-ip destination-ipv4-address destination-port destination-port-number [ vpn-instance vpn-instance-name ] [ verbose | wireshark ] [ last last-number ] slot slot-number
Display packet information about a disconnected IPv6 TCP connection that is traced.	display tcp trace cache-packet ipv6 source-ip source-ipv6-address source-port source-port-number destination-ip destination-ipv6-address destination-port destination-port-number [ vpn-instance vpn-instance-name ] [ verbose | wireshark ] [ last last-number ] slot slot-number
Display the TCP connection trace configuration and statistics.	display tcp trace information slot slot-number
Clear the connection and packet information about all disconnected TCP connections.	reset tcp trace cache

 

TCP connection trace configuration examples

Example: Tracing IPv4 TCP connections

Network configuration

As show in Figure 3, you can Telnet to Device B from Device A. Configure TCP connection trace on Device A to trace the TCP connection between Device A and Device B. When the connection is abnormally closed, you can use the trace information to locate disconnection reasons. Enable persistence for TCP connection trace configuration so that the configuration can survive Device A reboot.

Figure 3 Network diagram

‌

Prerequisites

·     Configure Device B as a Telnet server. For more information, see login management configuration in Fundamentals Configuration Guide.

·     Assign an IP address to each interface. (Details not shown.)

Procedure

1.     Configure TCP connection trace on Device A:

# Allow the TCP connection trace feature to trace a maximum of 600 data packets per TCP connection.

<DeviceA> tcp trace max-packet-number 600

# Set the memory quota to 300 MB for recording TCP connection information.

<DeviceA> tcp trace memory-quota 300

# Enable TCP connection trace.

<DeviceA> tcp trace enable

# Enable persistence for the TCP connection trace configuration.

<DeviceA> tcp trace persist

2.     Telnet to Device B from Device A.

<DeviceA> telnet 1.1.1.2

Verifying the configuration

1.     Display TCP connection information when you can correctly log in to Device B from Device A through Telnet.

# Display information about all disconnected IPv4 TCP connections that have been recorded.

<DeviceA> display tcp trace cache-connection ip

 R (Reason):

  PN: Peer normal close

  RR: Received reset

  SR: Sent reset

  AN: Application normal close

  AA: Application abnormal close

  KT: Keepalive timeout

  PT: Persist timeout

  RT: Retransmit timeout

  BD: Backup drop

 Local Addr:port       Foreign Addr:port     VPN name    R   Time

# Display packet information about disconnected IPv4 TCP connections.

<DeviceA> display tcp trace cache-packet ip source-ip 1.1.1.1 source-port 23 destination-ip 1.1.1.2 destination-port 23 verbose

The TCP connection is normal and no output is displayed.

2.     Shut down GigabitEthernet 1/0/1 on Device B.

<DeviceB> system-view

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] shutdown

After you shut down GigabitEthernet 1/0/1, the Telnet connection is terminated. Display TCP connection information on Device A after a period of time.

# Display information about all disconnected IPv4 TCP connections that have been recorded.

<DeviceA> display tcp trace cache-connection ip

 R (Reason):

  PN: Peer normal close

  RR: Received reset

  SR: Sent reset

  AN: Application normal close

  AA: Application abnormal close

  KT: Keepalive timeout

  PT: Persist timeout

  RT: Retransmit timeout

  BD: Backup drop

 Local Addr:port       Foreign Addr:port     VPN name    R   Time

 1.1.1.1:9732           1.1.1.2:23             N/A          RT  20:29:08

                                                                     July 1 2019

# Displays information about the last three packets that were traced before the TCP connection was closed.

<DeviceA> display tcp trace cache-packet ip source-ip 1.1.1.1 source-port 9732 destination-ip 1.1.1.2 destination-port 23 verbose last 3

 

 MDC ID: 1, Sep 18 15:38:58:503 2019, VPN name: N/A

 Connection: 1.1.1.1:9732 -> 1.1.1.2:23

 Reason: retransmit timeout

 sndmax/localackmax/scale/mss: 73/512/3/1448

 rcvmax/peerackmax/scale/mss: 512/67/3/0

 iss 2236101971, irs 3798739327, in 21 (drop 0), out 23, retrans 14

 connection time: Sep 18 15:29:39:003 2019

 

 (1) Sep 18 15:33:08:367 2019 RS

 seq 2236102038(67), ack 3798739839(512), data 6, NSR invalid (CLOSED)

 flag PSH ACK, status ESTABLISHED, win: 8145, csum: 0xeab6, ID: 200, ipcsum: 0x0

 iss/sndcc/unack/next/max/wnd: 2236101971/6/67/73/73/4344

 irs/rcvcc/undeliver/next/adv/wnd: 3798739327/0/0/512/65663/65160

 socket state: ISCONNECTED

 socket options: SO_OOBINLINE

 inpcb flags: INP_ANONPORT INP_PROTOCOL_PACKET INP_SYNCPCB

 inpcb extflag: N/A

 TCP options: TF_ACKNOW TF_REQ_SCALE TF_RCVD_SCALE TF_REQ_TSTMP TF_RCVD_TSTMP TF_SACK_PERMIT

 recv delayack: 0

 time start/offset/nsroffset start/lastrcv/tsrecent tsrecentage

 4310545007/0/0

 4310754371/15578830/15690748

 4310546126

 rexmt shift/current/seq rtt/srtt/var low/min/best updatetimes

 10/15560/2236102038 0/0/25

 2/30/68 9

 

 (2) Sep 18 15:33:23:928 2019 RS

 seq 2236102038(67), ack 3798739839(512), data 6, NSR invalid (CLOSED)

 flag PSH ACK, status ESTABLISHED, win: 8145, csum: 0xadee, ID: 201, ipcsum: 0x0

 iss/sndcc/unack/next/max/wnd: 2236101971/6/67/73/73/4344

 irs/rcvcc/undeliver/next/adv/wnd: 3798739327/0/0/512/65663/65160

 socket state: ISCONNECTED

 socket options: SO_OOBINLINE

 inpcb flags: INP_ANONPORT INP_PROTOCOL_PACKET INP_SYNCPCB

 inpcb extflag: N/A

 TCP options: TF_ACKNOW TF_REQ_SCALE TF_RCVD_SCALE TF_REQ_TSTMP TF_RCVD_TSTMP TF_SACK_PERMIT

 recv delayack: 0

 time start/offset/nsroffset start/lastrcv/tsrecent tsrecentage

 4310545007/0/0

 4310769931/15578830/15690748

 4310546126

 rexmt shift/current/seq rtt/srtt/var low/min/best updatetimes

 11/15560/2236102038 0/0/25

 2/30/68 9

 

 (3) Sep 18 15:33:39:488 2019 RS

 seq 2236102038(67), ack 3798739839(512), data 6, NSR invalid (CLOSED)

 flag PSH ACK, status ESTABLISHED, win: 8145, csum: 0x7126, ID: 202, ipcsum: 0x0

 iss/sndcc/unack/next/max/wnd: 2236101971/6/67/73/73/4344

 irs/rcvcc/undeliver/next/adv/wnd: 3798739327/0/0/512/65663/65160

 socket state: ISCONNECTED

 socket options: SO_OOBINLINE

 inpcb flags: INP_ANONPORT INP_PROTOCOL_PACKET INP_SYNCPCB

 inpcb extflag: N/A

 TCP options: TF_ACKNOW TF_REQ_SCALE TF_RCVD_SCALE TF_REQ_TSTMP TF_RCVD_TSTMP TF_SACK_PERMIT

 recv delayack: 0

 time start/offset/nsroffset start/lastrcv/tsrecent tsrecentage

 4310545007/0/0

 4310785491/15578830/15690748

 4310546126

 rexmt shift/current/seq rtt/srtt/var low/min/best updatetimes

 12/15560/2236102038 0/0/25

 2/30/68 9

The output shows that:

¡     The TCP connection between Device A and Device B has been closed.

¡     The disconnection reason is retransmission timeout. The client determines retransmission timeout because it does not receive any ACK packet from the server.

To resolve the issue, verify that the TCP server operates correctly and the link between the TCP client and server is connected.

Example: Tracing IPv6 TCP connections

Network configuration

As show in Figure 4, you can Telnet to Device B from Device A. Configure TCP connection trace on Device A to trace the IPv6 TCP connection between Device A and Device B. When the connection is abnormally closed, you can use the trace information to locate disconnection reasons. Enable persistence for TCP connection trace configuration so that the configuration can survive Device A reboot.

Figure 4 Network diagram

‌

Prerequisites

·     Configure Device B as a Telnet server. For more information, see login management configuration in Fundamentals Configuration Guide.

·     Assign an IPv6 address to each interface. (Details not shown.)

Procedure

1.     Configure TCP connection trace on Device A:

# Allow the TCP connection trace feature to trace a maximum of 600 data packets per TCP connection.

<DeviceA> tcp trace max-packet-number 600

# Set the memory quota to 300 MB for recording TCP connection information.

<DeviceA> tcp trace memory-quota 300

# Enable TCP connection trace.

<DeviceA> tcp trace enable

# Enable persistence for the TCP connection trace configuration.

<DeviceA> tcp trace persist

2.     Telnet to Device B from Device A.

<DeviceA> telnet ipv6 1::2

Verifying the configuration

1.     Display TCP connection information when you can correctly log in to Device B from Device A through Telnet.

# Display information about all disconnected IPv6 TCP connections that have been recorded.

<DeviceA> display tcp trace cache-connection ipv6

R (Reason):

  PN: Peer normal close

  RR: Received reset

  SR: Sent reset

  AN: Application normal close

  AA: Application abnormal close

  KT: Keepalive timeout

  PT: Persist timeout

  RT: Retransmit timeout

  BD: Backup drop

 LAddr->port             FAddr->port             VPN name   R   Time

# Display packet information about disconnected IPv6 TCP connections.

<DeviceA> display tcp trace cache-packet ipv6 source-ip 1::1 source-port 47745 destination-ip 1::2 destination-port 23 verbose

The TCP connection is normal and no output is displayed.

2.     Shut down GigabitEthernet 1/0/1 on Device B.

<DeviceB> system-view

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] shutdown

After you shut down GigabitEthernet 1/0/1, the Telnet connection is terminated. Display TCP connection information on Device A after a period of time.

# Display information about all disconnected IPv6 TCP connections that have been recorded.

<DeviceA> display tcp trace cache-connection ipv6

 R (Reason):

  PN: Peer normal close

  RR: Received reset

  SR: Sent reset

  AN: Application normal close

  AA: Application abnormal close

  KT: Keepalive timeout

  PT: Persist timeout

  RT: Retransmit timeout

  BD: Backup drop

 LAddr->port             FAddr->port             VPN name   R   Time

 1::1->47745             1::2->23                 N/A         RT  20:29:08

                                                                       July 1 2019

# Displays information about the last three packets that were traced before the IPv6 TCP connection was closed.

<DeviceA> display tcp trace cache-packet ipv6 source-ip 1::1 source-port 47745 destination-ip 1::2 destination-port 23 verbose last 3

 

 MDC ID: 1, Sep 18 16:20:20:091 2019, VPN name: N/A

 Connection: 1::1->47745 --> 1::2->23

 Reason: retransmit timeout

 sndmax/localackmax/scale/mss: 77/460/3/1428

 rcvmax/peerackmax/scale/mss: 460/59/3/0

 iss 2284338403, irs 1251751781, in 9 (drop 0), out 11, retrans 20

 connection time: Sep 18 16:15:49:827 2019

 (1) Sep 18 16:18:50:817 2019 RS

 seq 2284338462(59), ack 1251752241(460), data 18, NSR invalid (CLOSED)

 flag PSH ACK, status ESTABLISHED, win: 8211, csum: 0x6edb

 iss/sndcc/unack/next/max/wnd: 2284338403/18/59/77/77/4280

 irs/rcvcc/undeliver/next/adv/wnd: 1251751781/0/0/460/66139/65688

 socket state: ISCONNECTED

 socket options: SO_OOBINLINE

 inpcb flags: INP_ANONPORT INP_PROTOCOL_PACKET IN6P_IPV6_V6ONLY INP_SYNCPCB

 inpcb extflag: N/A

 TCP options: TF_ACKNOW TF_REQ_SCALE TF_RCVD_SCALE TF_REQ_TSTMP TF_RCVD_TSTMP TF_SACK_PERMIT TF_APP_SEND

 recv delayack: 0

 time start/offset/nsroffset start/lastrcv/tsrecent tsrecentage

 4313315830/0/0

 4313496820/18348628/18460545

 4313315924

 rexmt shift/current/seq rtt/srtt/var low/min/best updatetimes

 10/15560/2284338462 18529253/0/15

 1/30/64 5

 

 (2) Sep 18 16:18:58:881 2019 RS

 seq 2284338462(59), ack 1251752241(460), data 18, NSR invalid (CLOSED)

 flag PSH ACK, status ESTABLISHED, win: 8211, csum: 0x4f5a

 iss/sndcc/unack/next/max/wnd: 2284338403/18/59/77/77/4280

 irs/rcvcc/undeliver/next/adv/wnd: 1251751781/0/0/460/66139/65688

 socket state: ISCONNECTED

 socket options: SO_OOBINLINE

 inpcb flags: INP_ANONPORT INP_PROTOCOL_PACKET IN6P_IPV6_V6ONLY INP_SYNCPCB

 inpcb extflag: N/A

 TCP options: TF_ACKNOW TF_REQ_SCALE TF_RCVD_SCALE TF_REQ_TSTMP TF_RCVD_TSTMP TF_SACK_PERMIT

 recv delayack: 0

 time start/offset/nsroffset start/lastrcv/tsrecent tsrecentage

 4313315830/0/0

 4313504885/18348628/18460545

 4313315924

 rexmt shift/current/seq rtt/srtt/var low/min/best updatetimes

 11/15560/2284338462 0/0/15

 1/30/64 5

 

 (3) Sep 18 16:19:14:441 2019 RS

 seq 2284338462(59), ack 1251752241(460), data 18, NSR invalid (CLOSED)

 flag PSH ACK, status ESTABLISHED, win: 8211, csum: 0x1292

 iss/sndcc/unack/next/max/wnd: 2284338403/18/59/77/77/4280

 irs/rcvcc/undeliver/next/adv/wnd: 1251751781/0/0/460/66139/65688

 socket state: ISCONNECTED

 socket options: SO_OOBINLINE

 inpcb flags: INP_ANONPORT INP_PROTOCOL_PACKET IN6P_IPV6_V6ONLY INP_SYNCPCB

 inpcb extflag: N/A

 TCP options: TF_ACKNOW TF_REQ_SCALE TF_RCVD_SCALE TF_REQ_TSTMP TF_RCVD_TSTMP TF_SACK_PERMIT

 recv delayack: 0

 time start/offset/nsroffset start/lastrcv/tsrecent tsrecentage

 4313315830/0/0

 4313520445/18348628/18460545

 4313315924

 rexmt shift/current/seq rtt/srtt/var low/min/best updatetimes

 12/15560/2284338462 0/0/15

 1/30/64 5

The output shows that:

¡     The TCP connection between Device A and Device B has been closed.

¡     The disconnection reason is retransmission timeout. The client determines retransmission timeout because it does not receive any ACK packet from the server.

To resolve the issue, verify that the TCP server operates correctly and the link between the TCP client and server is connected.