Putting together what we've already done, we can filter on the following:
(tcp.flags.syn==1) || (tcp.seq==1 && tcp.ack==1) Wireshark Lab 32: Obtain RTT using Display Filters
Let's test the filter for the first two packets of the TCP handshake and then test our filter for the last two packets of the TCP handshake.
Step 1:
Open tr-chappellu.pcapng.
Step 2:
In the display filter area, enter the filter tcp.flags.syn==1 and click Apply.
Fifty-eight packets match this filter. The first two packets are sent from the client port 35,621. Packet 3 and Packet 4 are the first two packets of a new TCP connection. The TCP Delta column indicates the time from the TCP SYN from port 35,622 and the SYN/ACK to that same port, RTT is about 17 ms.
Although this trace file was captured at the client, we will use it to practice locating the second and third packet of the TCP handshake. These are the packets we would use to determine RTT when capturing at the server.
Step 3:
In the display filter area, enter the following filter:
(tcp.flags.syn==1 && tcp.flags.ack==1) || (tcp.seq==1 &&
tcp.ack==1)
Click Apply and examine the results. Sixty-nine packets match this filter. There are several packets that are not of interest to us, however.
For example, Packets 14 and 15 are the second and third packets of the TCP handshake, but Packet 16 is the first HTTP command sent after the handshake. Our filter is displaying this packet because the Relative sequence number value is 1 and the Relative Acknowledgment Number value is 1. We can add && tcp.len==0 to our filter to remove these packets from view.
Packets 698 through 706 are FIN packets. These FIN packets are also being displayed because of the Relative Sequence Number and Relative Acknowledgment Number values. We can add &&
tcp.flags.fin==0 to remove these packets from view.
Step 4:
Enhance your filter with these two additional conditions:
(tcp.flags.syn==1 && tcp.flags.ack==1) || (tcp.seq==1 &&
tcp.ack==1) && tcp.len==0 && tcp.flags.fin==0
Click Apply. Now you should see only the SYN/ACK and ACK packets of the handshakes in the trace file. Your TCP Delta column illustrates the time between each of these packets in each of the TCP conversations.
Step 5:
Click Clear to remove your filter before continuing.
Consider saving two filter expression buttons—one for the first two packets of the handshake and another for the second and third packet of the handshake. Name these buttons TCP HS1-2 and TCP HS2-3. These two filter expression buttons can be used to quickly identify high path latency.
Next we will create an Advanced IO Graph to detect TCP delays in a trace file.
Wireshark Lab 33: Graph TCP Delays
You can use Wireshark's Advanced IO Graph to graph the maximum tcp.time_delta value to locate TCP conversation delays in a trace file.
Step 1:
Open tr-chappellu.pcapng.
Step 2:
Select Statistics | IO Graph.
Step 3:
In the Y Axis Unit area, select Advanced...
Step 4:
Select the MAX(*) Graph 1 Calc option and enter tcp.time_delta in the Calc area. We will first work without a filter at this time.
Step 5:
Click the Graph 1 button to graph your results.
The graph indicates that there is a spike in the RTT values around 25 seconds into the trace file.
Click on this high point in the graph and Wireshark will jump to that packet in the main Wireshark window. Notice the value in the TCP Delta column—15.757807 seconds.
If you look at that packet (Packet 155), this is a TCP FIN packet. That is not a delay we care about.
To make this graph more usable, we will add a filter to remove acceptable delays from view.
Step 6:
In the Filter area of Graph 1, enter the following filter:
tcp.time_delta > 1 && tcp.flags.fin==0 && tcp.flags.reset==0 &&
!http.request.method=="GET"
This is the same display filter you created in Wireshark Lab 30: Add a "TCP Delay" Button.
You will need to click the Graph 1 button again to enable the graph to use this filter.
The new graph highlights fewer problems because we've removed many false positives from view.
When we click on the largest delay point in this graph, Wireshark jumps to Packet 86. (Remember to toggle back to your IO Graph to close it once you have finished this lab.)
If you see different results when creating this graph, check to ensure your TCP Calculate conversation timestamps preference setting is enabled (see TCP Preference: Calculate
Conversation Timestamps). Also ensure your TCP Allow subdissector to reassemble TCP streams preference setting is disabled (see Wireshark Lab 11: Change the TCP Dissector Reassembly Setting to Properly Measure HTTP Response Times).
This packet is a TCP SYN retransmission packet that arrived almost 6 seconds after the previous packet in this TCP stream (which would also be a TCP SYN packet). We can see the indication of a connection request that is not receiving responses.
Always consider time when you are troubleshooting network performance. A 20 ms delay probably isn't going to be felt by the end user. A 20 second delay is going to be felt. Try to prioritize your troubleshooting to eradicate the biggest delays first. That's what the users will appreciate most.[24]