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:Spurious Retransmission Sample

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:SVN Change Log Spurious Retransmission

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.

Spurious Retransmission

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.

Discussions — 23 Responses

  • Jose Naranjo October 26, 2014 on 9:39 pm

    This was really helpful, thanks!

  • Mario October 29, 2014 on 4:39 pm

    Thanks from Brazil!

    • Marcus Thiago Lages Duarte Mario March 27, 2017 on 4:34 pm

      We have a very similar word in portuguese, “espúrio”. 😉

  • Christian Reusch October 29, 2014 on 9:58 pm

    This is really a good explanation.

    And it is good that we now can filter on such kind of retransmissions.

  • Chris November 17, 2014 on 11:13 pm

    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.

    • Jasper Bongertz Chris November 17, 2014 on 11:22 pm

      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.

      • Quilnux Jasper Bongertz October 4, 2016 on 3:28 pm

        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.

        • Jasper Bongertz Quilnux October 4, 2016 on 3:34 pm

          This kind of attack would require the attacker to know the correct sequence numbers though, which means he needs to be watching the connection.

      • geertn Jasper Bongertz October 27, 2016 on 5:02 pm

        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”

  • Beldum June 26, 2015 on 12:03 am

    Wow excellent! This helped give an excellent explanation on what spurious retransmission is.

  • Bruno July 18, 2015 on 12:47 am

    I am using the free Wi – Fi and this means that the signal bouncing . Therefore double it arrives .

  • ChunZhou November 12, 2015 on 4:43 am

    its very useful.

    Thanks from China.

  • James January 21, 2016 on 1:05 pm

    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 🙂

  • noriko February 12, 2016 on 2:36 pm

    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?

    • Jasper Bongertz noriko February 12, 2016 on 2:45 pm

      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.

      • George Cao Jasper Bongertz February 24, 2016 on 4:37 pm

        Hi Jasper Bongertz,

        I use this command to capture packets on client side.
        tcpdump -w 68.dump ‘port 12507’

        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.

        • Jasper Bongertz George Cao February 24, 2016 on 4:56 pm

          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.

          • George Cao Jasper Bongertz February 25, 2016 on 2:14 am

            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?

  • Brandon April 3, 2017 on 5:32 pm

    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?

    • Jasper Brandon April 3, 2017 on 5:40 pm

      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.

  • Syed April 24, 2019 on 1:08 pm

    What happens for the spurious packet at the receiving end ? will it be ignored or processed ?

    • Jasper Syed April 24, 2019 on 1:11 pm

      That depends on the TCP stack – usually it is ignored, because the data is most likely already passed on to the application layer.