Are you registered for my "Troubleshooting with Wireshark" webinar this week? If not, click here to register for the event at 10:00am PDT (UTC-7) on Thursday. It will be either directly recorded (or recorded cleanly right after the event) and put up in the All Access Pass this week.
So you opened up that trace file and found it contained Spurious Retransmissions.
Should you be worried? What triggers Wireshark to mark packets as Spurious Retransmissions? What do these Spurious Retransmissions mean?
Let's take a look at tcp-spurious-retran.pcapng. This trace file is available at https://www.chappell-university.com/traces. Why not download this file and follow along with me?
The single TCP conversation in this trace file depicts a client establishing a TCP connection followed by a TLS connection. Not much else happens after that and the client abruptly terminates the TCP connection. We are focusing on the Spurious Retransmissions in this trace file.
This trace file contains only 22 packets. I filtered all other traffic from view before saving so that we could focus only on Spurious Retransmissions for this blog.
Frames 14 and 20 are marked as Spurious Retransmissions in this trace file. Let's take a look at the reason those packets are marked as Spurious Retransmissions.
Spurious Retransmissions Defined
Spurious Retransmissions are one's that are considered unnecessary -- in Wireshark, a retransmission is marked as "spurious" when Wireshark has seen the ACK for the data already.
Let's take a glance inside Wireshark's TCP dissector to see what the Wireshark development team wrote about Spurious Retransmissions.
To open the Wireshark TCP dissector and see the code defining Spurious Retransmissions, visit wireshark.org and select Develop | Browse the Code | epan | dissectors and open the packet-tcp.c file.
The notes clarify that a Spurious Retransmission contains a Sequence Number + Length value that is less than the most recently received ACK.
Spurious Retransmissions in Wireshark's Expert
The Wireshark Expert offers a fast way to detect Spurious Retransmissions in a trace file. That little circle in the bottom left corner of the Wireshark window is the Expert button. Here's what Wireshark Expert displays for our tcp-spurious-retran.pcapng file.
Spurious Retransmission Display Filter
Another way to detect Spurious Retransmissions is with a display filter for tcp.analysis.spurious_retransmission.
In the profile I created for this blog, I added a button called "SPURs" to quickly detect Spurious Retransmissions in a trace file.
If you've taken any of my classes or keynote sessions, you know by now that I LOVE buttons! Buttons, buttons, buttons! This key feature of Wireshark enables you to automate many of your analysis processes.
Analyzing a Spurious Retransmission
The image below depicts the traffic leading up to the Frame 14 Spurious Retransmission seen inside the tcp-spurious-retrans.pcapng trace file.
Notice that Frame 10 from the server used Sequence Number 4381 and contained 1438 bytes of data. The next Sequence Number from the server should be 5819. The ACK from the client (Frame 11) acknowledged the server's Sequence Numbers up to, but not including, 5819. So far, everything looks normal.
Frames 12 and 13 are from the client - they contain TLS handshake information.
Frame 14 from the server is the first Spurious Retransmission in this trace file. Why would this server resend Sequence Number 4381 when we clearly see it has been acknowledged in Frame 11?
Frame 20 is another Spurious Retransmission. It appears as a duplicate of Frame 18 (which was ACKed in Frame 19 already).
The Most Likely Causes of Spurious Retransmissions
What causes a host to retransmit a data packet that has already been ACKed?
Cause 1: The ACK did not Arrive at the Host within the Retransmission Timeout
Oh sure, we saw the ACK in the trace file, but we were capturing at the client and not along the path or at the server. What if the ACK didn't make it to the server in this example? In that case, the server is doing exactly what it should do - it is retransmitting the data packet after its Retransmission Timeout (RTO) timer expired.
Regardless of whether the ACK has been dropped along the path or it has just been delayed beyond the RTO value, the result is the same. The server must retransmit the unacknowledged data packet.
Notice in our network diagram, we captured at the client. If the ACK didn't make it to the server, this isn't really a Spurious Retransmission - it's just a standard Retransmission. Wireshark must mark it as a Spurious Retransmission because the ACK was seen in the trace file.
Cause 2: The Retransmitting TCP Stack is Faulty
What if the ACK arrived, but for some reason, the TCP stack did not process the ACK? In this case, you'd look directly at the server to see what could be wrong. This is the less-likely cause of the Spurious Retransmission, however. Don't go down this rabbit hole unless you've captured directly at the sender of Spurious Retransmissions and you can validate that ACKs are truly arriving at the host, but appear not to be processed.
If you suspect a misbehaving TCP stack, set up a capture directly at the host that is sending Spurious Retransmissions. In this case, we'd capture directly on the server.
How Harmful are Spurious Retransmissions?
Keep in mind that a few Spurious Retransmissions here and there are typically not cause for alarm.
If you start seeing an increase in Spurious Retransmissions over time or you encounter a LOT of Spurious Retransmissions in your trace files, spend some time finding the root cause.
If you are experiencing packet loss - look for an infrastructure device as the most likely cause of dropped ACKs. You will likely find that you also have "Previous Segment(s) Not Captured" throughout your trace file as that infrastructure device is probably dropping data packets as well as the ACK packets.
If you see the ACKs arriving as expected, you appear to have a misbehaving TCP stack. Consider replacing the stack or the system - it is an indication of strange, faulty behavior.
Cheers!
WANT TO LEARN MORE? We offer on-demand, online and instructor-led courses on Wireshark and TCP/IP communications! Check out the links under "Training" on the menu for more information!
Sign up for our biweekly newsletter to know when future blogs, events, or freebies are announced. Every new sign up also gets five free labs!