top of page
  • Writer's pictureLaura Chappell

Detect Suspicious Traffic with "TCP Conversation Completeness"

In my last blog entry, I explained how Wireshark calculates TCP Conversation Completeness based on the TCP flags and whether data is seen in a TCP conversation (stream).

To use this feature, I recommend that you add three columns to Wireshark:

[The fastest way to add these three columns is to click and drag the following fields to the column header area - Stream index, Conversation completeness, and Completeness Flags.]

[Yes - I recommend you create a profile for "TCP Completeness" and add these columns to that new profile. Also add a column as you see in the image below.]

Wireshark conversation completeness column

Now grab the following trace file and open it in Wireshark. Sort the Packet List pane based on the Stream index column.

At first, you will see a bunch of UDP-based traffic (DNS, ICMP, and basic UDP packets). You can apply a filter for tcp, if desired. Alternately, just scroll down until you see Frame 5 or 9 (they are both part of TCP stream 0).

This stream's TCP conversation is "incomplete" with R - - A - S shown for the Completeness flags. Reset, ACK, and SYN have been seen in this conversation.

A quick reminder of the values assigned for TCP completeness:

32 : RST

16 : FIN

8 : DA

4 : ACK


1 : SYN

Now, let's use this value to detect suspicious TCP traffic - you can see how we got 37 for conversation completeness. That's not a number we'd expect for a "normal" conversation. The fact that this is an odd number indicates that we saw the SYN packet. In that case, we'd expect to see SYN-ACK, ACK, DATA, and FIN or Reset.

We would expect to see either 31 or 47.

Could you create a display filter to detect this unusual TCP completeness value? Sure you can! Use tcp.completeness == 37.

This trace file contains a LOT of questionable TCP conversations. Spend a moment looking through all the TCP Conversation Completeness values shown.



bottom of page