This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

What does RST/ACK convey in this capture excerpt?

0
973 24.130685   10.160.119.23   172.16.1.242    TCP 54  **50078 → 443 [RST, ACK] Seq=1180** Ack=1677 Win=0 Len=0
974 24.134424   172.16.1.242    10.160.119.23   TCP 60  **[TCP Dup ACK 967#1] 443 → 50078 [ACK]** Seq=1677 Ack=1179 Win=131328 Len=0
975 24.134557   10.160.119.23   172.16.1.242    TCP 54  50078 → 443 [RST] Seq=1179 Win=0 Len=0
976 24.136172   172.16.1.242    10.160.119.23   TCP 60  443 → 50078 [ACK] Seq=1677 Ack=1180 Win=131328 Len=0
977 24.136275   10.160.119.23   172.16.1.242    TCP 54  50078 → 443 [RST] Seq=1180 Win=0 Len=0
978 24.835189   10.160.119.2    224.0.0.2   HSRP    62  Hello (state Standby)
This question is marked "community wiki".

asked 06 Jan '17, 03:14

implementation's gravatar image

implementation
6112
accept rate: 0%

edited 06 Jan '17, 03:52

grahamb's gravatar image

grahamb ♦
19.8k330206


One Answer:

0

We have a client (10.160.119.23) and a server (172.16.1.242). The client made an HTTPS request, which is not shown in the trace file.

The client acknowledges the arrival of data [Ack=1179, while the ACK flag is set] and want's to terminate the connection [RST].

Data is still in transit from the server, while the RST is on it's way (packets 974 and 976). As the client has already closed it's socket the two data segments trigger extra Resets.

A graceful TCP shutdown would require 4 packets:

          C -> S   FIN
          S -> C   ACK, thank you for your FIN
optional  S -> C   by the way, I still got some data to you
optional  S -> C   blah, blah, blah
          S -> C   FIN
          C -> S   Thank you, good bye

Terminating the connection makes sure, that the server will not send data after the client tells about the desire to terminate the connection.

answered 06 Jan '17, 09:41

packethunter's gravatar image

packethunter
2.1k71548
accept rate: 8%