6.1.7 Lab: Explore Three-way Handshake In Wireshark

Explore the Three-Way Handshake in Wireshark: A Deep Dive into TCP Connection Establishment

Understanding how a reliable connection is born between two devices on a network is a cornerstone of networking knowledge. That's why the TCP three-way handshake is that foundational process, a silent, automated negotiation that happens every time you load a webpage, send an email, or stream a video. On the flip side, this hands-on lab guide will walk you through capturing and analyzing this critical process using Wireshark, the world’s premier network protocol analyzer. By the end of this exploration, you will not only see the handshake but truly understand the sequence of flags, sequence numbers, and acknowledgments that build the bedrock of TCP communication.

Introduction: Why the Three-Way Handshake Matters

Before any application data can flow between a client and a server using the Transmission Control Protocol (TCP), a connection must be established. This isn't a simple "hello"; it's a deliberate, three-step process designed to synchronize sequence numbers, negotiate initial parameters, and confirm bidirectional communication channels are open. It ensures both sides are ready and agree on the starting point for data transmission, providing the reliability TCP is famous for. Observing this handshake in Wireshark transforms an abstract concept into a concrete, packet-level reality, revealing the elegance of the protocol's design.

Lab Setup and Preparation

To successfully conduct this lab, you need:

1. Wireshark installed on your computer (available free from wireshark.org).
2. A network connection (Wi-Fi or Ethernet).
3. A simple method to generate TCP traffic. The easiest is opening a web browser and navigating to any website (e.g., http://example.com). Each new connection to a web server will initiate a handshake.

Crucial First Step: Start Wireshark and begin capturing on the active network interface before you generate the traffic. This ensures the handshake packets are not missed.

Step-by-Step: Capturing and Isolating the Handshake

1. Initiate the Capture

Launch Wireshark. You will see a list of network interfaces. The one with traffic activity (often indicated by a graph or packet count) is your active interface. Double-click it to start capturing. You’ll see packets scrolling in real-time.

2. Generate the Traffic

With capture running, open your web browser and type a URL, then press Enter. This action causes your computer (the client) to initiate a TCP connection to the web server on port 80 (for HTTP) or 443 (for HTTPS) That's the part that actually makes a difference..

3. Stop and Filter the Capture

After the webpage starts loading, you can stop the capture. The stream of packets is overwhelming. To find the handshake, use Wireshark’s powerful display filter. Type the following into the filter bar and press Enter: tcp.flags.syn == 1 and tcp.flags.ack == 0 This filter shows only the first packet of the handshake: the SYN (Synchronize) packet sent from the client to the server. You should see at least one result.

To see the entire handshake sequence more clearly, a better filter is one that isolates a single TCP conversation. On the flip side, find a SYN packet in the list, right-click on it, and select "Follow" > "TCP Stream". This opens a window showing the entire conversation. Close this window; Wireshark will automatically apply a filter like tcp.So port == 54321 && tcp. port == 80 (ports will vary) to show only packets for that specific connection Most people skip this — try not to. Practical, not theoretical..

4. Identify the Three Packets

With your conversation filtered, you should now see a clear sequence of three packets that stand out. They are the handshake:

1. Packet 1: Client → Server. Flags: [SYN]. This is the initial request.
2. Packet 2: Server → Client. Flags: [SYN, ACK]. This is the server's response.
3. Packet 3: Client → Server. Flags: [ACK]. This is the client's final acknowledgment.

If you don't see this exact sequence, ensure you filtered correctly and that your initial capture started before the browser request.

Scientific Breakdown: Analyzing Each Handshake Packet

Click on the first packet (SYN). Expand the "Transmission Control Protocol" section in the packet details pane. Here’s what to examine:

• Source Port & Destination Port: The client uses a random, high-numbered ephemeral port (e.g., 54321). The destination is the well-known service port (80 for HTTP, 443 for HTTPS).
• Sequence Number: This is a 32-bit random value chosen by the client (e.g., Seq=0). It's the starting point for the client's data stream. Crucially, the SYN packet itself consumes one sequence number, so the first byte of actual data the client sends will have a sequence number of initial_seq + 1.
• Acknowledgment Number: In a SYN packet, this field is 0 (or empty), as there is nothing to acknowledge yet.
• Flags: The SYN flag is set to 1. This is the key indicator.

Now, click the second packet (SYN-ACK):

• Source/Destination Ports: Now reversed. Server source port (80) to client destination port (54321).
• Sequence Number: The server's own randomly chosen initial sequence number (e.g., Seq=2896543211).
• Acknowledgment Number: This is the critical response. It will be client_initial_seq + 1 (e.g., Ack=1). This tells the client, "I received your SYN, and I'm acknowledging the next expected byte, which is your sequence number plus one."
• Flags: Both SYN and ACK flags are set to 1.

Finally, the third packet (ACK):

• Source/Destination Ports: Back to client → server.
• Sequence Number: Now client_initial_seq + 1 (e.g., Seq=1). The client is now sending its first actual byte of data (which might be an HTTP GET request).
• Acknowledgment Number: server_initial_seq + 1 (e.g., Ack=2896543212). This acknowledges the server's SYN.
• Flags: Only the ACK flag is set to 1.

This exchange perfectly establishes the initial sequence numbers for both directions of the data flow. The connection is now ESTABLISHED, and application data (like your HTTP request) can begin.

Common Pitfalls and Troubleshooting

• "I only see two packets!" You likely started the capture after the SYN was sent. Always start Wires

Common Pitfalls and Troubleshooting

• "I only see two packets!Now, g. Look at the Delta time column; increasing intervals point to retransmissions due to packet loss or an unresponsive server.
  " This can indicate a firewall dropping the server’s reply, a mis‑routed packet, or the server not listening on the expected port. Examine the payload of the SYN‑ACK; any data there indicates a middlebox interfering with the handshake.
  "** The client may be retransmitting the SYN because it didn’t receive a SYN‑ACK within the retransmission timeout (typically 1 s, then 2 s, 4 s, etc.And "** You likely started the capture after the SYN was sent. Wireshark’s Relative sequence numbers (enabled by default) help you see the logical progression; if you suspect wrap‑around, disable relative numbering and verify that the absolute values increase monotonically modulo 2³².
  Now, "** If the client’s ACK acknowledges a number far beyond server_initial_seq + 1, it suggests that the server sent data (perhaps a banner or HTTP response) before the three‑way handshake completed—this can happen with TCP accelerators or proxies that spoof the handshake. This leads to , with telnet or nc) and check any intermediate security devices for SYN‑cookie or rate‑limit policies. Plus, verify that the destination IP and port are reachable (e. ** Duplicate ACKs often signal that a segment was lost and the receiver is repeatedly acknowledging the last in‑order byte it received. Consider this: ). Here's the thing — , Ack=1 repeated). Because of that, * **"Sequence numbers appear to wrap or reset mid‑capture. On the flip side, g. * *"The ACK number in the third packet is off by more than one. *"I see duplicate ACKs (e. "I see multiple SYN packets with the same source port.Always start Wireshark (or your capture tool) a few seconds before initiating the request, or use a capture filter that begins recording as soon as traffic appears on the interface.
  " On high‑speed links, the 32‑bit sequence space can recycle quickly. In real terms, * **"The SYN‑ACK never arrives. Follow the duplicate ACKs with a fast retransmission or a timeout; this is useful for diagnosing packet loss on the path.

Quick Checklist for a Clean Handshake Capture 1. Start capture early – before the application initiates the connection.

2. Use a capture filter like tcp[tcpflags] & (tcp-syn|tcp-ack) != 0 to focus on SYN/SYN‑ACK/ACK traffic if you’re only interested in the handshake.
3. Verify IP reachability with a simple ping or traceroute to rule out routing issues. 4. Check for middleboxes – look for unexpected TCP options (e.g., MSS, window scaling) or data in SYN/ACK packets.
4. Monitor retransmissions – Wireshark marks them with [TCP Retransmission]; note the timing to gauge loss severity.

Conclusion

The three‑way TCP handshake is a concise yet powerful mechanism that synchronizes initial sequence numbers, negotiates optional features, and transitions both endpoints into the ESTABLISHED state. By examining the SYN, SYN‑ACK, and ACK packets in Wireshark—paying close attention to source/destination ports, sequence and acknowledgment numbers, and flag settings—you can confirm that a connection is being set up correctly or pinpoint where the process breaks down. Common issues such as mistimed captures, missing SYN‑ACKs, retransmissions, or interference from middleboxes become evident once you know what each field should contain. Armed with this systematic approach, you can troubleshoot TCP‑based applications with confidence, ensuring reliable and efficient network communication.