Ask Your Question
0

Communication keeps on restarting between Source and Client, noticed RST, ACK.

asked 2021-11-12 00:49:16 +0000

updated 2021-11-12 09:38:35 +0000

grahamb gravatar image

Hi All,
I have been facing a issue between my devices (Server and RTU device) where the communication gets initiated and immediately resets and starts the whole cycle again. I noticed that Wireshark logs showing RST, ACK highlighted in red colour and am not sure if that is the problem. I have redundant servers and when I force the communication to other server the RTU device works fine. I did a ping check and there are no TCP timeouts between Server and RTU device. RTU is Remote Terminal Unit used for field device communication.

Below shows issue between Server 10.211.14.126 and RTU 10.211.173.119.

10.211.14.126   10.211.173.119  TCP 1434    [TCP Retransmission] 64420 → 1090 [ACK] Seq=1772 Ack=8651 Win=262144 Len=1380
10.211.14.126   10.211.173.119  TCP 1434    [TCP Retransmission] 64420 → 1090 [ACK] Seq=1772 Ack=8651 Win=262144 Len=1380
10.211.14.126   10.211.173.119  TCP 54  64420 → 1090 [RST, ACK] Seq=3152 Ack=8651 Win=0 Len=0
10.211.173.119  10.211.14.126   TCP 60  1090 → 64394 [FIN, ACK] Seq=8651 Ack=1772 Win=8280 Len=0
10.211.14.126   10.211.173.119  TCP 54  64394 → 1090 [RST] Seq=1772 Win=0 Len=0
10.211.14.126   10.211.173.119  TCP 66  64457 → 1090 [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
10.211.173.119  10.211.14.126   TCP 62  1090 → 64457 [SYN, ACK] Seq=0 Ack=1 Win=8280 Len=0 MSS=1380 WS=1
10.211.14.126   10.211.173.119  TCP 54  64457 → 1090 [ACK] Seq=1 Ack=1 Win=262144 Len=0

After this the communication resets and gets initiated again.

Below shows working communication between Server 10.211.14.127 and RTU 10.211.173.119.

10.211.14.127   10.211.173.119  TCP 1434    [TCP Retransmission] 56669 → 1090 [ACK] Seq=1772 Ack=8651 Win=262144 Len=1380
10.211.14.127   10.211.173.119  TCP 1434    [TCP Retransmission] 56669 → 1090 [ACK] Seq=1772 Ack=8651 Win=262144 Len=1380
10.211.14.127   10.211.173.119  TCP 590 [TCP Retransmission] 56669 → 1090 [ACK] Seq=1772 Ack=8651 Win=262144 Len=536
10.211.173.119  10.211.14.127   TCP 60  1090 → 56669 [ACK] Seq=8651 Ack=2308 Win=7744 Len=0
10.211.14.127   10.211.173.119  TCP 590 [TCP Retransmission] 56669 → 1090 [ACK] Seq=2308 Ack=8651 Win=262144 Len=536
10.211.14.127   10.211.173.119  TCP 590 [TCP Retransmission] 56669 → 1090 [ACK] Seq=2844 Ack=8651 Win=262144 Len=536
10.211.173.119  10.211.14.127   TCP 60  1090 → 56669 [ACK] Seq=8651 Ack=2844 Win=7744 Len=0
10.211.14.127   10.211.173.119  TCP 186 [TCP Retransmission] 56669 → 1090 [PSH, ACK] Seq=3380 Ack=8651 Win=262144 Len=132
10.211 ...
(more)
edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
1

answered 2021-11-12 10:03:45 +0000

grahamb gravatar image

Working on the little information shown in the text (a capture file is so much easier to work with), in the first exchange it seems that the RTU is failing to acknowledge transmissions from the server and so the server gives up and closes the connections with the RST.

In the 2nd exchange, the server is again sending retransmissions, but this time the RTU does respond and so the TCP session can continue.

This is basic TCP retransmission handling. The missing ACK's from the RTU could be dropped anywhere on the path from the RTU to the server, including either endpoint, so you'll have to capture at various points to determine the culprit.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2021-11-12 00:49:16 +0000

Seen: 389 times

Last updated: Nov 12 '21