Spurious Retransmissions
Update: since Wireshark version 1.12 is out, lots of people look for the meaning of “tcp spurious retransmission” info message, 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:
Tracking the code change
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.
This was really helpful, thanks!
Thanks from Brazil!
We have a very similar word in portuguese, “espúrio”. 😉
This is really a good explanation.
And it is good that we now can filter on such kind of retransmissions.
I just came across the same thing and found that this was happening after a SYN packet didn’t reach its destination.
So “Spurious Retransmission” doesn’t always mean it’s a “needless transmission”.
In my case, there was a firewall denying it.
Source sent SYN, destination was expecting it but didn’t receive so it sent a [RST, ACK].
Then the next SYN attempt showed up as TCP Spurious Retransmission.
Then went back and forth until the client gave up.
Well, I still have to make up my mind if I’d call a SYN that was sent again for whatever reason (first one gets blocked/lost) a retransmission. For me a retransmission happens for established sessions, and without the full three way handshake we don’t have one. But there are other opinions, so it’s hard to say who’s right 🙂
And a SYN that needs to be sent twice or more (because the first did not get answered) is most certainly not “spurious” (if I take the meaning of the word of it being forged/untrue/unnecessary), but useful.
Keep in mind that under some circumstances, a hijacked connection can be closed and/or controlled by an attacker of the attacker manages to convince the network or system that it is sending legitimate packets in addition to the legitimate system.
One example would be an attacker trying to close a connection between two legitimate parties, and succeeding. The other sending party then sends a packet with the same packet ID after the attacker (or even then attacker sending it after the sender). It can indicate the channel was snooped or hijacked since two systems (attackers and the legitimate sender) are sending out the same packet at or around the same time. The receiver might consider them to be the same sender even though they are not. So in some circumstances, this helps security professionals find out if a connection has been hijacked.
This kind of attack would require the attacker to know the correct sequence numbers though, which means he needs to be watching the connection.
I completely agree. I am having the case of repeated SYN packets where the SYN-ACK gets back to the host, but not to the protocol stack. Probably a firewall blocks the inbound packet. Anyway, multiple SYN with the same source and destination ports always indicate trouble. It should get another warning as “retransmission”
Wow excellent! This helped give an excellent explanation on what spurious retransmission is.
I am using the free Wi – Fi and this means that the signal bouncing . Therefore double it arrives .
its very useful.
Thanks from China.
This is still a very good post. Thank you for writing it.
I’m diagnosing a perculiar networking issue, and the rabbit hole has gotten – frankly – ridiculous. I’m expecting a packet to come along with an “eat me” label on soon.
Top quality post though. Thank you 🙂
Very good article, thanks.
I have a similar but not identical problem – I see SYN+ACK spurious retransmission from the server and then duplicate ACK from the client.
Do you have an idea how that is possible?
Is it because server lost ACK from the client or maybe the server resends SYN+ACK if it sees no traffic from the client?
If you see a spurious SYN+ACK it seems that the ACK from the client is lost on it’s way to the server, so the server re-sends the SYN+ACK as it assumes it hasn’t arrived at the client. This kind of phenomenon should only be observed if you capture at the client. Capturing at the server should show the missing ACK not arriving.
Hi Jasper Bongertz,
I use this command to capture packets on client side.
tcpdump -w 68.dump ‘port 12507’
then
tcpdump -r 68.dump ‘port 12507’ -nS -tt
output the following:
1456279683.081348 IP 10.x.x.x.12507 > 10.y.y.y.8353: Flags [S], seq 1752345815, win 11680, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0
1456279684.080595 IP 10..x.x.x.12507 > 10.y.y.y.8353: Flags [S], seq 1752345815, win 11680, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0
It says the client sends two SYN requests at the beginning of initiate a connection, right? Wired, can you help me with this? If you are intrested, I can send you a email to provide more info.
Captures on client are always problematic; you should try to capture on a device that is just recording and not being part of the conversation. Otherwise you may be chasing ghosts and packets that were never really sent.
Actually i captured packets on both sides. Another wired thing is on the server side, tcpdump received two SYN requests, so the client should have sent the SYN requests to the server, right?
I’m also seeing spurious syn, ack from client and spurious ack from server.
The communication is fine both ways, I can see the client send the client hello, and the server respond with a server hello.
Then everything breaks down into the Spurious retransmissions.
Could this be a result of certificate issues?
I don’t think that those are certificate issues, at least I have never seen that happen. Maybe those are just duplicates? You can easily test that by deduplicating the PCAP using “editcap -d “. If editcap removes packets from your file they are most certainly duplicates, and the “spurious retransmissions” just ghosts.
What happens for the spurious packet at the receiving end ? will it be ignored or processed ?
That depends on the TCP stack – usually it is ignored, because the data is most likely already passed on to the application layer.