Introduced in version 3.6 and later is a new Wireshark expert analysis process called TCP Completeness. At first this was quite confusing, but once you get to know what is going on, you come to understand that you can use this new feature to find certain types of TCP issues. We included this is our TCP Troubleshooting Profile almost immediately, and have updated the profile multiple times as more clarity has been attained with regards to how we can use the feature.
Let’s start with a simple understanding of how TCP Completeness works when everything is normal. TCP is a stateful and connection oriented protocol. This means that a good TCP connection goes through three phases:
- Connection Establishment (SYN – SYN, ACK – ACK)
- Data Transfer
- Connection Termination (FIN, FIN-ACK, FIN, FIN-ACK)
What we have below is a simple TCP session that goes through all three phases perfectly in 10 total packets:
If you look into the TCP header, you will see the TCP Completeness information that is in brackets, meaning this information is not actually in the packet headers, but rather has been added by the Wireshark Expert Analysis processes.
We see that in the example above the completeness is labeled as “Complete, WITH_DATA and then given a value of 31.
What does this mean?
Let’s begin with the number value and the nomenclature being used. The number value is derived from the following reference:
The numbers are additive as the communication process travels down the communication ladder illustrated. Note that you only add the value of 8 once even though there may be multiple DATA packets. This is true for the other packet types as well.
Seems simple enough, so let’s look back up to the normal and complete 10-packet conversation above. The value was 31 – this is 1 (for the SYN) plus 2 (for the SYN-ACK) plus 4 (for the ACK) plus 8 (for the DATA) plus 16 (for the FIN). You will see a lot of these in your TCP troubleshooting travels. Again, very normal
But what about problems? Let’s walk through some scenarios and see how this works.
TCP Completeness = 1
This can be caused by a TCP SYN scan – in this case you would see many of these to multiple addresses. Another cause would be an invalid Sender IP address – the Receiver is trying to connect to an invalid place. It could also mean that the SYN-ACK response from a valid Sender was lost, and therefore nothing further happened.
TCP Completeness = 3
The conversation did not complete as the establishment is really only half way done. What happened to the ACK? Could it have been lost? Could a Firewall be blocking traffic? This is not normal and could result in receivers experiencing “slow Internet”.
TCP Completeness = 7
Well, the connection got established but then nothing further was exchanged. Very not normal. Once has to question whether there are proxy servers or Firewalls in the way here.
TCP Completeness = 15
This could mean one packet of data, or multiple packets of data – basically the connection termination is missing. Either the packet capture missed the packets, or the FIN packets were dropped due to congestion. If the packets are dropped, it is likely that the connections would eventually terminate/reset.
TCP Completeness = 31
TCP Completeness = 33
This is not a good thing. It means the Sender is unable to accept connections. If the sender is busy this situation may be temporary, and again the end user experiences slow Internet.
TCP Completeness = 63
It is not clear that this is any type of issue other than just an interesting behavior instead of a polite FIN-ACK.
TCP Completeness = 55
Very interesting. Why would the response have no data? Certainly not a networking issue, but perhaps a Sender/Server issue.
The Bottom Line
I find this new feature to be a great enhancement to what Wireshark can do to help us troubleshoot TCP. It is an interesting concept and you can easily add display filters that can leverage this new expert information. Here are some example filters I use in the TCP profile from the repository (https://www.cellstream.com/wireshark-profiles-repository/):
When troubleshooting you will first find the completeness setting, then select a packet and then use the TCP conversation filter to isolate that TCP conversation and diagnose what is going on.