XXX add brief explanation to these events This should be broken out to its own page with a more detailed explanation. For example, if the TCP WindowSize is too small to accommodate a high end-to-end latency this will be indicated by TCP WindowFull and in that case there will not be any TCP ZeroWindow indications at all. Do note that this can occur even if no ZeroWindow condition is ever triggered. When this event occurs, a ZeroWindow condition might occur on the other host and we might see TCP ZeroWindow segments coming back. This causes delays in the flow of data between sender and receiver and lowers throughput. The sender, knowing that it has sent enough data to fill the last known RX window size, must now stop sending until at least some of the data is acknowledged (or until the acknowledgement timer for the oldest unacknowledged packet expires). TCP WindowFull - This flag is set on segments where the payload data in the segment will completely fill the RX buffer on the host on the other side of the TCP session. Once the application on the receiver retrieves data from the TCP buffer, thereby freeing up space, the receiver should notify the sender that the TCP ZeroWindow condition no longer exists by sending a TCP WindowUpdate that advertises the current window size. Typically seen after a TCP ZeroWindow condition has occurred. A WindowUpdate occurs when the application on the receiving side has consumed already received data from the RX buffer causing the TCP layer to send a WindowUpdate to the other side to indicate that there is now more space available in the buffer. TCP WindowUpdate - This indicates that the segment was a pure WindowUpdate segment. TCP ZeroWindowViolation - The sender has ignored the zero window condition of the receiver and sent additional bytes of data. If the window is still zero, the sender will double his persist timer before probing again. TCP ZerowindowProbe - The sender is testing to see if the receiver's zero window condition still exists by sending the next byte of data to elicit an ACK from the receiver. Indicates a resource issue on the receiver, as the application is not retrieving data from the TCP buffer in a timely manner. This effectively tells the sender to stop sending because the receiver's buffer is full. TCP ZeroWindow - Occurs when a receiver advertises a receive window size of zero. A clear indication of dropped/missing packets. If the receiver detects a gap in the sequence numbers, it will generate a duplicate ACK for each subsequent packet it receives on that connection, until the missing packet is successfully received (retransmitted). TCP DupACK - Occurs when the same ACK number is seen AND it is lower than the last byte of data sent by the sender. ACK packet sent in response to a 'keep-alive' packet. TCP Keep-Alive - Occurs when the sequence number is equal to the last byte of data in the previous packet. This event is a good indicator of packet loss and will likely be accompanied by 'TCP Retransmission' events.

TCP Previous segment lost - Occurs when a packet arrives with a sequence number greater than the 'next expected sequence number' on that connection, indicating that one or more packets prior to the flagged packet did not arrive. TCP_Out-of-order - Occurs when a packet is seen with a sequence number lower than the previously received packet on that connection. Senders should Fast Retransmit upon receipt of 3 duplicate ACKs. Senders receive some packets which sequence number are bigger than the acknowledged packets. TCP Fast Retransmission - Occurs when the sender retransmits a packet before the expiration of the acknowledgement timer. TCP Retransmission - Occurs when the sender retransmits a packet after the expiration of the acknowledgement. When this feature is enabled the sliding window monitoring inside Wireshark will detect and trigger display of interesting events for TCP such as : This feature should not impact too much on the run-time memory requirements of Wireshark but can be disabled if required. This allows much better and more accurate measurements of packet-loss and retransmissions than is available in any other protocol analyzer. This requires some extra state information and memory to be kept by the dissector but allows much better detection of interesting TCP events such as retransmissions.

See the TCP Analysis section of the User's Guide for more up to date documentation.īy default Wireshark and TShark will keep track of all TCP sessions and implement its own crude version of Sliding_Windows.

Wireshark tcp retransmission syn