Previously in the packet trace I can see that the TCP 3-way handshake succeeded (and succeeds EVERY time a connection attempt was made). The above traffic is filtered to a window that shows the error state. Appliances that lack a native ability to capture traffic / PCAP files contributes to less direct troubleshooting paths.įor reference, here is an image that shows the type of traffic I was seeing on a system attempting to initiate a secure session: This issue took longer to troubleshoot than I would have liked due to the specialized nature of endpoints involved. The core problem was an MTU mis-match between our gigabit network and our 100-megabit VPN tunnel.

I performed a comprehensive analysis of our networking infrastructure and router configurations and captured PCAP files to gather enough data to root cause the problem. Some machines were unable to communicate at all while other machines could occasionally and sporadically establish a connection that would fail at inopportune times. We paid a 'cost' of 200ms because the server's burst had an odd number of packets.We had a mysterious issue in our network that caused certain SSH sessions and HTTPS/TLS sessions to fail intermittently. This one second delay is purely due to the client. The next action in this connection Is another GET after around 1 second. Note the 'Left Edge = 23361 & Right Edge = 24062' in the TCP Options/SACK detail. In response to the unnecessary 'spurious' retransmission (#194), the receiver sends a Duplicate-SACK (D-SACK, #195).Ī D-SACK is the use of the SACK mechanism to inform the sender that it has sent duplicate data (#194 = #150). The receiver sends a Delayed ACK (#192 - an ACK to #150) and almost at the same time receives #194 (a retransmission of #150 - sent after a Retransmission Timeout at the sender). #150 is the last packet of the burst and isn't ACKed because the receiver sends an ACK only for every two packets (normal behaviour).īoth sides now timeout after around 200ms. Packet #149 ACKs everything up to packet #148 data.

I realise that this is a very old question, so the answer is probably too late for the original poster - but may be of interest to anyone finding this post now.

Tcp dup ack wireshark