Hi, I can't find any documentation on this code "60" about "conversation completeness". I've a lot of this incomplete connections. Has Wireshark a service to analyze a problem?
TCP conversation completeness is a bitwise field where the occurance of certain flags over the conversation is recorded and then every packet in the TCP conversation gets that value for conversation completeness. The flags being recorded are:
1 - SYN from client 2 - SYN/ACK from server 4 - bare ACK (any direction) 8 - data (any direction) 16 - FIN (any direction) 32 - RST (any direction)
Which means a TCP conversation with completeness value 60 has seen a bare ACK, data, a FIN and a RST, but no SYN from the client and no SYN/ACK from the server. In short, the capture was started in the middle of the session. That's why it is marked as "Incomplete".
The bits of that field are defined by Wireshark, not by any protocol, so there's no protocol-level significance to the value 60. It's the individual bits, as per @SYN-bit, that matter; in this case, they mean, as he indicates, that, because the packet capture was started in the middle of the TCP session, Wireshark didn't see the connection being established, it just saw data transferred after the connection was established and then saw the end of the connection (which involved an RST).
Perhaps that field should explain what at least some values mean.
Perhaps that field should explain what at least some values mean.
It does, the tree item has a subtree which lists the individual flags. Therefore I asked "What else does it say?", to see if OP is aware of this fact, or guide to it. Whether the (decimal) value has any significance, other than a value to filter on, is debatable IMHO.
Many thanks to all
It means that flag bits RST, FIN, DATA, and ACK are all set.
" receiving a packet with both FIN and RST flags set can lead to confusion, as the RST flag typically overrides the FIN flag and abruptly closes the connection."
FWIW: It would appear that this type of packet could be used in a buffer overrun attack, by "faking" a FIN and RST thus forcing the overflow ??
@bugChaser The FIN and RST flags set might have been seen in the same packet, but most probably were seen in different packets (as tcp.completeness tracks the whole TCP session), which would be quite normal for TLS conversations these days.
Asked: Dec 28 '3
Seen: 1,392 times
Last updated: Jan 22
Would you be so kind as to explain your question?
What else does it say, beyond code "60"?
Documentation in the WSUG: 7.5. TCP Analysis
See these Gitlab issues for related discussions:
18911: TCP Completeness elaborate by expand option
19092: TCP Conversation Completeness : FTP created conversations issue