Checkout

Cart () Loading...

    • Quantity:
    • Delivery:
    • Dates:
    • Location:

    $

When is a TCP SYN not a SYN?

Date:
Oct. 07, 2013
Author:
Betty DuBois

Answer? When it is flagged as a retransmission in Wireshark!

One thing that makes Wireshark the world’s most popular protocol analyzer is how often the open-source tool is updated. A major release goes out at least twice annually, with multiple “dot” releases, a.k.a. bug fixes, in between. Also, new features sometimes slip into a “dot” revision. I am one of those people who actually reads the release notes, so I was very excited to see that Wireshark 1.10.1 now flags a retransmitted TCP synchronize (SYN) packet with an Expert Info Message. This is something I used to have to hunt for with filters. Now I can just go to Analyze | Expert Info | Notes, and they will be listed for me. See screenshot below:

wireshark1

TCP Handshake: The Conversation Starter
Transmission Control Protocol (TCP) is the most pervasive protocol on the Internet, and it starts with a three-way handshake. Step one: the client asks, “Hey server, do you have port 80 open? I want to synchronize (SYN). I’ll listen for your response on port 42,678.” Step two: the server responds, “Hey client, do you have port 42,678 open (SYN)? I have port 80 open, come on in (ACK)." Finally in step three, the client responds, “Port 42,678 is ready, come on in (ACK)." There are additional items negotiated during the handshake, but I am focusing on just the SYN+SYN/ACK packets for this discussion.

No SYN/ACK – Why Not?
What happens when you are capturing closer to the client, and the server does not respond? There are many reasons this could happen:


  • At the client location, the firewall could block it, or the proxy server could be overloaded and drop it

  • In the cloud, any router along the path could drop the packet due to its queues being overloaded or the packet was physically damaged in transit

  • At the server location, the firewall could block it, or the server could be overloaded and not respond


How Does the Client Try to Recover?
The client will simply back off based on its operating systems algorithm and retransmit the SYN. In the screenshot below, the client retransmits every one second and when that is unsuccessful, changes its options and begins to double the back off. This is a signature of a UNIX-based operating system. A Windows client will wait three seconds and then double the back off timer and retransmit. Either way, now that Wireshark flags these retransmissions, they are easier to find and, therefore, isolate the cause.

wireshark2

Related Courses
TCP/IP Networking

Troubleshooting TCP/IP Networks with Wireshark