Update: since Wireshark version 1.12 is out, lots of people look for the meaning of “spurious retransmissions”, so I changed the post a little to make it easier to find what you’re looking for.
Today, while doing a lot of testing of my trace handling code as well as in preparation for the upcoming Sharkfest 2013, I got a trace sample from Landi that he wanted me to take a look at because he wondered about some SSL decoding stuff. So I did, and while we were talking about what the SSL dissector was doing I saw a new TCP expert message I had never seen before: “TCP Spurious Retransmission”.
Well, my english is not so bad, but I had no clue what this kind of retransmission was supposed to be (or even what the word “spurious” meant :-)), especially in a SYN packet, which had never been marked as a retransmission before:
It turned out that Landi didn’t get those expert messages in his version of Wireshark, so I guessed that it had to be something that was changed pretty recently, since I was using the 1.11 developer version (for verifying some bug reports that had been closed) and he was on 1.10 stable. So I fired up my SVN tool to get the latest code revision and took a look at “packet-tcp.c” in the dissector directory. It turned out that two changes had been made that explained the screen shot above, one by the Joe from Cloudshark, and one by Sake:
The older change was to add an expert message when a segment was seen that was transmitting data older than the last segment that the receiver had requested.
What does “Spurious Retransmission” mean?
Basically “Spurious Retransmission” means that data was sent again that the receiver had already acknowledged, which is something that we used to call “needless retransmission” in our own expert system. “Needless” probably doesn’t sound technically weird enough, so in papers about those retransmissions they were labeled “spurious”. There is a bug report where the patch was mentioned at https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8614
If you’re seeing spurious retransmissions it means that the sender thought packets were lost and sent them again, even though the receiver sent an acknowledge packet for it.
To find out why it does that you would need a capture close to the sender to see what the situation is at that location. Maybe the acknowledge packet got lost, so the sender could not know that the packet got through and assumed it was lost.
Spurious SYN packets
So far, so good. The question was now, why were repeated SYN packets marked as “spurious retransmissions”? The change Sake introduced to “packet-tcp.c” was to mark repeated SYN and FIN packets as retransmissions, which wasn’t the case before. Now, in combination with the first code change, repeated SYN packets to a closed port will show up like in the screen shot.
I’m not sure it is a good idea to mark repeated SYN packets as retransmissions since the TCP session isn’t technically open yet, and it leads to confusion (“I must have packet loss, because there are retransmissions”), but I’ll talk to Sake at Sharkfest and we’ll probably find a common point of view over a beer or two 😉
If you want to take a look at spurious retransmissions the guys at Cloudshark have put up a sample at https://www.cloudshark.org/captures/3e24a14eabc1.