Understanding “TCP Conversation Completeness” in Wireshark
A Deep Dive into What It Really Means (and What It Doesn’t)
When analyzing TCP packet captures in Wireshark, you may have noticed a column or field called “TCP Conversation Completeness.” It often shows up as a numerical value — 7, 15, 31, 63, and so on — and many engineers assume it reflects the health of a TCP connection or compliance with RFC 793.
However, that’s not what it is.
TCP Conversation Completeness is a Wireshark-specific analytical feature, not a TCP protocol metric or a network standard. It tells you only what Wireshark observed in the packet trace — not necessarily what happened on the wire end-to-end.
In this article, we’ll break down how Wireshark computes it, what the values mean, how incomplete captures can distort it, and how to correctly interpret it in real-world troubleshooting.
TCP Conversation Completeness” is like Wireshark’s health summary for a TCP connection —
useful for triage, not for truth
This critical TCP-layer metric that can significantly enhance how we validate the health of incoming client connections. The parameter is called “Conversation Completeness”, and while it may sound like a technical jargon, it is a highly effective diagnostic for analyzing connection integrity. This metric helps us categorize TCP conversations into meaningful states, such as:
🔴 Incomplete: Handshake not completed (e.g., SYN sent but no ACK)
🟠 Partial Data: Handshake succeeded, but data exchange was interrupted
🔥 Reset Immediately: Connections rejected abruptly (RST seen)
⏱️ Late SYN-ACK:
SYN and SYN-ACK seen, but final ACK from client is missing(Common under
high latency, packet loss, or asymmetric routing issues)
⚪ No Data: Clean handshake and closure, but no application data transferred
🟢 With Data: Full connection with data exchanged and properly closed
⚠️ Duplicate Conversations: Multiple flows for the same connection(May indicate monitoring artifacts or NAT reuse)
To assess connection health, we’ve classified traffic into the following TCP health buckets: Healthy TCP % = Sum of all Complete, WITH_DATA codes (31, 47, 63) divided by Total.
🟢 Green (Excellent): ≥ 97.5%, 🟡 Yellow (Good): 90–97.49%, 🟠 Amber (Moderate): 70–89.99%, 🔵 Blue (Below Average): 50–69.99%, 🔴 Red (Poor): < 50%
Observation for Client 6:
- TTL = 126: Suggests Windows OS
- Window Size = 8192
- Window Scale = 8 (resulting in an effective receive window of 2,097,152 bytes)
- MSS = 1338
- tcp.completeness == 23:
- All 1528 connections (initiated every hour) follow the 3-way handshake — SYN → SYN-ACK → ACK — but then terminate immediately with a FIN,ACK without exchanging any application data or TLS handshake.
What Is TCP Conversation Completeness?
TCP Conversation Completeness means that every TCP connection observed in packet capture has a proper beginning, middle, and end according to the TCP finite state machine.
A complete TCP conversation typically consists of:
- Three-way handshake — SYN → SYN-ACK → ACK
- Data exchange — One or both directions transmit data packets with PSH or ACK
- Graceful termination — A full four-way FIN/ACK handshake, ensuring both sides close cleanly
Any deviation — like missing handshakes, abrupt resets, or unacknowledged FINs — indicates incomplete conversation(s).
| Type | Description | Example Frames (Wireshark) | Remarks |
|---|---|---|---|
| Complete Conversation | Full SYN, data exchange, and 4-way FIN/ACK closure observed | SYN → SYN-ACK → ACK → [Data] → FIN → ACK → FIN → ACK | Ideal, healthy connection |
| Incomplete (Reset) | Connection aborted using RST instead of FIN | SYN → SYN-ACK → ACK → [Data] → RST | Application error or abrupt termination |
| Incomplete (Unidirectional FIN) | One side closes, the other doesn’t | SYN → SYN-ACK → ACK → [Data] → FIN → ACK (missing other FIN) | Peer-side timeout or closure mismatch |
| Handshake Incomplete | SYN sent but never acknowledged | SYN (no SYN-ACK) | Port closed, firewall drop, or routing issue |
| Midstream Reset | Data exchange occurs, then abrupt RST | SYN → SYN-ACK → ACK → [Data] → RST | Common during protocol mismatch, timeout, or app crash |
Wireshark tracks the lifecycle of each TCP connection based on the flags it sees during capture:
| TCP Event | Description |
|---|---|
SYN | Connection initiation by client |
SYN, ACK | Server acknowledgment |
ACK | Final step of 3-way handshake |
DATA | Application payload transfer |
FIN | Graceful close request |
RST | Abrupt termination |
Wireshark uses these observed events to compute a bitmask value, stored in the field tcp.completeness.
Each bit in this field corresponds to a stage of the TCP conversation. The combination of bits forms a numeric “completeness score” that Wireshark can display as a value or text label.
📊 Why TCP Completeness Matters
Even when application logs show “Transaction Approved”, incomplete TCP flows can reveal deep network or system issues:
| Impact Area | Example Scenario | Hidden Symptom |
|---|---|---|
| Load Balancer or Firewall | Connection reset due to idle timeout | App sees random disconnections |
| Server Configuration | Keep-alive disabled or FIN ignored | Half-open sockets pile up |
| Client Behavior | App abruptly closes sockets | Server stuck in LAST_ACK |
| TLS Handshake | Client aborts mid-handshake | SSL failure without clear error |
| Retransmission Storms | MSS or window scaling mismatch | Spikes in latency or CPU load |
🧠 Anatomy of a Complete vs. Incomplete TCP Conversation
| Type | Description | Common Pattern in Wireshark | Health |
|---|---|---|---|
| ✅ Complete Conversation | Full handshake, bidirectional data, clean 4-way FIN | SYN → SYN-ACK → ACK → Data → FIN/ACK → FIN/ACK | Healthy |
| ❌ Reset Termination | Connection aborted using RST | SYN → SYN-ACK → ACK → Data → RST | Application crash, firewall reset |
| ⚠️ One-Sided FIN | One side closes, peer never replies | SYN → SYN-ACK → ACK → Data → FIN → ACK (no peer FIN) | Half-open session |
| ⚠️ Handshake Incomplete | No SYN-ACK received | SYN only | Port closed, firewall drop |
| ❌ Midstream Reset | Reset during data exchange | SYN → SYN-ACK → ACK → Data → RST | Timeout, misbehavior, or mismatch |
Bitmask Breakdown
Below is a simplified interpretation of how Wireshark defines the TCP Conversation Completeness bitmask:
| Decimal | Binary | Meaning | Typical Interpretation |
|---|---|---|---|
1 | 000001 | SYN seen | Connection attempt initiated |
3 | 000011 | SYN + SYN-ACK | Two sides initiated handshake |
7 | 000111 | SYN + SYN-ACK + ACK | Full 3-way handshake observed |
15 | 001111 | Handshake + data transfer | Established connection with data |
31 | 011111 | Handshake + data + FIN | Normal close seen (4-way termination) |
63 | 111111 | Handshake + data + FIN + RST | Connection established, data sent, and reset seen |
You can view this value in Wireshark using:
Frame → Expand “Transmission Control Protocol” → Field: tcp.completeness
Or create a column by right-clicking and selecting “Apply as Column”.
Important Clarification: This Is a Wireshark Construct
“TCP Conversation Completeness” is not defined in any TCP RFC or OSI layer standard.
It’s a Wireshark-level convenience metric designed to help analysts quickly summarize what parts of the TCP lifecycle were seen in the capture — nothing more.
That means it’s entirely capture-dependent, not network-absolute.
Why It Changes with Incomplete or Asymmetric Captures
If your packet trace is incomplete — due to asymmetric capture, packet drops, or the trace starting/stopping midway — Wireshark’s completeness analysis will change.
Let’s look at some examples:
Example 1: Partial Handshake
If you start the capture after the client has already sent the SYN, Wireshark will only see:
SYN, ACK → ACK
The completeness score will not include the original SYN, so it may show as 3 (incomplete handshake), even though the real network connection is already established.
Example 2: Missing FIN
If you stop the capture before the connection gracefully closes, Wireshark won’t see the FIN packets. The completeness will remain at 15 (handshake + data), even if the TCP connection properly closed afterward.
Example 3: One-Way Capture (Asymmetric Routing)
If your capture is on only one side of the network path (e.g., on the client), you might only see:
SYN → SYN, ACK (missing)
Wireshark can’t infer that the other side replied — so it’ll report a very low completeness, even though the server did respond in reality.
How to Interpret It Correctly
Think of TCP Conversation Completeness as a summary of what Wireshark observed, not a verdict on whether the TCP session succeeded.
Here’s a practical interpretation table:
| Completeness | Meaning (in Wireshark) | What It Might Indicate |
|---|---|---|
1 or 3 | SYN or SYN+ACK only | Connection attempt, no response |
7 | Full handshake, no data | Idle TCP connection |
15 | Handshake + data | Normal session, may be truncated |
31 | Handshake + data + FIN | Graceful closure (4-way handshake complete) |
63 | Includes RST | Connection terminated abruptly |
So if you see a 15, it might mean:
- Normal session without closure, or
- Capture stopped before FIN was sent, or
- Server or client didn’t follow graceful termination.
To tell which one applies, inspect the trace context — timestamps, packet directions, and sequence numbers.
Practical Tips for Accurate Completeness Analysis
| Tip | Why It Matters |
|---|---|
| Capture both directions (bi-directional) | Avoid missing SYN/ACK or FIN/ACK packets |
| Start capture before the SYN | Ensures handshake is included |
| End capture after FIN/RST | Captures full closure |
| Avoid SPAN oversubscription | Prevents packet drops |
| Verify with sequence numbers | Detect missing data beyond completeness bitmask |
| Use tcp.analysis.flags | To correlate retransmissions, dup ACKs, etc. |
Combining Completeness with Application Context
While completeness gives a structural view of the TCP session, pairing it with application-layer visibility (e.g., HTTP, TLS, or custom payloads) helps you understand:
- Was data actually exchanged after handshake?
- Did the application issue proper FIN?
- Did the server or client abort the session?
For example:
- tcp.completeness = 31 with HTTP 200 OK → successful web transaction.
- tcp.completeness = 63 with TLS Alert: Close Notify → clean TLS closure.
- tcp.completeness = 15 with RST at end → likely timeout or forced disconnect.
Limitations and Common Misinterpretations
| Misconception | Reality |
|---|---|
| “Completeness 63 means fully successful connection.” | Not necessarily — it only means all flag types were seen. The session may have ended in RST. |
| “Low completeness = network failure.” | Could simply be partial capture or unidirectional sniffing. |
| “It’s part of TCP standard.” | No — it’s internal to Wireshark’s analysis engine. |
| “You can use completeness to measure success rate.” | Only valid if captures are full and symmetric. |
Example Wireshark Display
You can display the completeness column by:
- Right-clicking on any TCP packet → Protocol Preferences → Apply as Column.
- Adding a custom column with field name: tcp.completeness
- Optionally add color filters:
- tcp.completeness < 7 → Red (incomplete handshakes)
- tcp.completeness >= 15 → Green (active connections)
- tcp.completeness >= 31 → Blue (gracefully closed)
Key Takeaways
- TCP Conversation Completeness is Wireshark-defined, not TCP-standardized.
- It indicates what Wireshark has seen, not what truly happened end-to-end.
- It’s most useful when captures are full, symmetric, and continuous.
- For meaningful analysis, correlate with timestamps, sequence numbers, and application logs.
📐 Formula: TCP Conversation Completeness
Wireshark’s tcp.completeness field quantifies the health of each TCP conversation using a bitmask formula.
This numerical code describes which TCP events (SYN, ACK, DATA, FIN, RST) were seen in the capture — allowing analysts to instantly classify whether a connection was complete, partial, or aborted.
🧮 The TCP Completeness Bitmask
Each observed TCP event contributes a bit value:
| Bit | Name | Field Name | Meaning | String Representation |
|---|---|---|---|---|
| 1 | SYN | tcp.completeness.syn | SYN packet seen (client initiated connection) | S |
| 2 | SYN-ACK | tcp.completeness.syn-ack | SYN-ACK seen (server responded) | SA |
| 4 | ACK | tcp.completeness.ack | ACK seen (client completed handshake) | A |
| 8 | DATA | tcp.completeness.data | Application data exchanged | D |
| 16 | FIN | tcp.completeness.fin | Graceful closure attempt | F |
| 32 | RST | tcp.completeness.rst | Abrupt termination/reset | R |
The bitmask sum of these values represents the “conversation signature.” For instance,
63 (1+2+4+8+16+32) → SYN + SYN-ACK + ACK + DATA + FIN + RST → Ideal complete connection
Main Category | Subcode (Bitmask N) | Subtype Description | Meaning |
🔴 Incomplete | 2 | SYN or mid-flow only | Partial connection, handshake not completed |
5 (1 + 4) | SYN + ACK seen, missing ACK or RST | Often blocked or interrupted after handshake | |
13 (1 + 4 + 8) | Early close after SYN + ACK + ACK | Connection closed immediately after handshake, likely no app activity | |
35 (1 + 2 + 32) | Handshake + data, no closure | Data exchanged but connection was cut mid-way | |
37 (5 + 32) | Multiple data packets, no closure | Multiple payloads exchanged, then dropped | |
38 (1 + 2 + 4 + 32) | SYN + SYN-ACK + ACK + minimal data, drop | Very short data exchange, abruptly interrupted | |
59 (3 + 8 + 16 + 32) | Long flow, unusual closure | Extended exchange but closed in a non-standard or abrupt manner | |
62 (2 + 4 + 8 + 16 + 32) | Data + no FIN or RST | Payload sent, but no TCP closure observed | |
🟠 Incomplete, SYN_SENT | 1 | SYN seen only | Client sent SYN, no server reply |
🟠 Incomplete, CLIENT_ESTABLISHED | 3 (1+2) | SYN + SYN-ACK only | Server replied to SYN, client ACK not seen |
🟠 Incomplete, ESTABLISHED | 7 (1 + 2 + 4) | Full handshake, no data | Connection established, but no traffic exchanged |
🟠 Incomplete, DATA | 15 (1 + 2 + 4 + 8) | Handshake + some data, no closure | Abrupt interruption after data start |
35 (1 + 2 + 32) | Extended version of above | Same as 15 but more data packets | |
37 (1 + 4 + 32) | Repeated mid-stream drops | Slightly longer flows with no closure | |
🔥 Reset Immediately | 17 (1 + 16) | SYN followed by RST | Server forcefully rejected connection |
⏱️ Late SYN-ACK | 33 (1 + 32) | SYN + SYN-ACK only, delayed ACK | Likely network latency or asymmetric capture |
⚪ Complete, NO_DATA | 7 (1 + 2 + 4) | Full handshake, no data | Connection opened, no payload sent |
23 (7 + 16) | Full handshake + FIN | Graceful close without application data | |
55 (7 + 16 + 32) | Handshake + no payload + RST/FIN | Connection established but closed without sending any data | |
🟢 Complete, WITH_DATA | 31(1 + 2 + 4 + 8 + 16) | Data + one-sided FIN | Clean on one side, the other didn't close |
47(1 + 2 + 4 + 8 + 16 + 16) | Data + RST (Reset) | Connection closed abruptly after data | |
63(1 + 2 + 4 + 8 + 16 + 32) | Ideal connection | Handshake, data exchange, and proper closure (FIN/FIN-ACK) | |
⚠️ Duplicate Conversations | Varies | Tool-specific overlaps | Multiple rows for the same connection due to parsing |
Interpreting the Bitmask Formula
General Rule:
TCP_COMPLETENESS = SYN(1) + SYN-ACK(2) + ACK(4) + DATA(8) + FIN(16) + RST(32)
Wireshark displays this as:
tcp.completeness == <numeric_value>
tcp.completeness.str == <symbolic_string>
Example Filters:
| Goal | Filter |
|---|---|
| Show only complete TCP sessions | tcp.completeness == 63 |
| Show incomplete or reset sessions | tcp.completeness < 63 |
| Show connections without data | tcp.completeness == 7 or tcp.completeness == 23 |
| Show abrupt resets | tcp.completeness & 32 |
📊 Practical Use in Wireshark
- Go to Statistics → Conversations → TCP
- Add the “TCP completeness” column (if not visible)
- Each flow will show:
- Numeric bitmask (tcp.completeness)
- Symbolic representation (tcp.completeness.str)
- Example:
- Sort by completeness to instantly find failed or truncated sessions.
🧠 Why This Matters for Engineers
The tcp.completeness metric is effectively a conversation fingerprint.
It allows you to:
- Rapidly distinguish between graceful, reset, and half-open sessions
- Correlate packet traces with app-layer behavior
- Quantify TCP health (e.g., “98.9% of TCP sessions reached completeness = 63”)
- Detect capture gaps, asymmetric routing, or device-level aborts
| Value | Pattern | Meaning |
|---|---|---|
| 1 (S) | SYN only | Client attempted, no response |
| 7 (S A A) | Full handshake, idle | Connection opened, no data |
| 15 (S A A D) | Handshake + data, incomplete close | Abrupt stop |
| 31 (S A A D F) | Clean on one side | Server/client missing final FIN |
| 63 (S A A D F R) | Full, ideal flow | Handshake + data + proper closure |
🧷 Summary
TCP Conversation Completeness Formula = the DNA of a TCP flow.
Each bit tells part of the story — who spoke first, who replied, who sent data, who closed properly, and who dropped abruptly.
When combined with packet-level validation practices, it transforms Wireshark from a diagnostic tool into a quantitative network quality meter.
No comments:
Post a Comment