Tools · Network tools · 10 / 24
tshark: conversations, endpoints, and the protocol tree
Statistics answer who talked to whom and how much, without printing every frame. -q keeps the packet list out of the way so the table is the whole result.
What a conversation table is
tshark -q -z conv,tcp reads the file and prints one row per TCP socket pair: frames and bytes each way, totals, a relative start, and a duration. The manual says the table is sorted by total frames. UDP has conv,udp. IP pairs, without ports, are conv,ip. You add a display filter after the type when the statistic should ignore the rest of the file: conv,tcp,ip.addr==10.8.0.20.
-q matters. Without it, tshark prints every frame and then the table. On a lab file that is mostly noise, the table is the artifact you wanted. Endpoints are the other cut: -z endpoints,ip lists addresses and how much each sent and received. Protocol hierarchy, -z io,phs, says what share of the file was TCP, UDP, DNS, or TLS.
How a defender reads the rows
Sort your attention by the ticket, not by the biggest row. A backup that should be small and is the largest TCP conversation is the interesting line. A large conversation between two addresses the scope never named is a reason to check whether the capture filter was too wide, not a reason to investigate that pair.
Bytes in the conversation table are on-wire counts for that pair, which is a different number from tcpdump's length field. Say which table you quoted. Duration tells you whether the bulk was a short spike at 10:14 or a session that ran the whole capture.
- conv,tcp is socket pairs. conv,ip collapses ports.
- endpoints,ip answers which hosts appear at all.
- io,phs is the protocol mix. A file that is almost all TLS will show that here.
- A display filter after the comma limits the statistic to frames that match.
A worked defensive case
The files ticket claims 10.8.0.20 only talks to 10.8.0.40. You run conv,tcp limited to 10.8.0.20. The table shows a short pair with 10.8.0.40 on port 443, and a much larger pair from 10.8.0.20 to 10.8.0.27 on port 443 during the same file. Both addresses are inside the lab scope.
You add the unexpected pair to the ticket with its byte counts and duration, and you point the owner at 10.8.0.27. You do not print the frames of that pair into chat. If they need the contents, the next step is their application log or a field extract of metadata, because the hierarchy view already showed the bytes sitting under TLS.
Where this is documented
tshark(1) documents -z conv,type[,filter], -z endpoints, and -z io,phs, and it lists tcp, udp, and ip among the conversation types. -q suppresses the packet list so the statistic stands alone.
Use a host-only lab network, or a capture the owner already handed you. These commands read that file or record a single lab host. They are not a scan of the public internet.
Commands
tshark -r /lab/evidence.pcap -q -z conv,tcp,ip.addr==10.8.0.20
tshark -r /lab/evidence.pcap -q -z endpoints,ip -z io,phs
Diagram
From a pcap to a table of who talked
- File
The lab pcap stays sealed. -r reads it once for the statistic.
- Cut
conv,tcp with a display filter keeps the ticket's host.
- Row
Each row is a socket pair, with bytes each way and a duration.
- Ticket
Quote the unexpected pair and the counts. Leave unrelated hosts out.
Check yourself
1. You want one row per TCP pair and no packet list. Which command matches?
2. The statistic should ignore every host except 10.8.0.20. Where does that limit go?
3. The largest row is 10.8.0.20 to 10.8.0.27, port 443, and io,phs shows that portion as TLS. What goes in the ticket?