Conversations and endpoints
Conversations are pairs. Endpoints are hosts. The checkbox for the display filter decides which file you just counted.
A conversation is a pair
Statistics, then Conversations, groups the file into pairs. The TCP tab is the one you want for connections: address and port on each side, packets and bytes in each direction, and a relative start time. The IPv4 tab collapses ports, so one host talking to another on many ports becomes a single row. Pick the tab that matches the question.
A TCP row is the practical definition of a connection in the file. Select one and apply it as a filter. You land on tcp.stream for that row, which is the same index Follow would have used. Bytes A to B and bytes B to A tell you who sent the bulk. A row with a handful of packets and almost no bytes is a connection that never carried an application exchange.
An endpoint is one address
Statistics, then Endpoints, groups by address. A host that opened many connections appears once, with a packet count that sums them. This is the view that makes a noisy lab client obvious, and it is the view that hides which ports were involved. Use endpoints to pick the host, then conversations to pick the connection.
The limit-to-display-filter checkbox is the control that matters most in both windows. With the box clear, the table is the whole file, even if the packet list is filtered. With the box set, the table matches the list. Read the checkbox before you quote a number, and write “whole file” or the filter string next to the number.
ip.addr == 10.8.0.40 && ip.addr == 10.8.0.20
Worked case: one client, many short TCP rows
The lab mirror file is 20 minutes long. Endpoints, limited to the display filter ip.addr == 10.8.0.0/24, shows 10.8.0.40 with far more packets than the other clients. You switch to Conversations, TCP tab, same checkbox, and filter the idea of that host. Most rows are 10.8.0.40 to 10.8.0.20 port 443, with hundreds of kilobytes. Three rows are 10.8.0.40 to 10.8.0.20 on ports 22, 445, and 3389, each with a SYN and a RST and almost no bytes.
Those three rows are refused attempts, visible as conversations that never grew a payload. The HTTPS rows are the actual work. A single endpoints line for 10.8.0.40 would have blended them. You note the three refused ports separately from the byte-heavy 443 conversations, and you keep the display filter in the note so the counts can be repeated.
The same tables without the window
tshark prints these tables from a file you already have. -q -z conv,tcp is the TCP conversation list. -q -z endpoints,ip is the address list. Add -n so names do not creep into a table you are about to paste into notes. A display filter with -Y applies to the packets those tables see when you pass it that way, and you still write the filter next to the paste.
Sort your attention the way the window does. Large byte counts are transfers. One-packet or two-packet TCP rows are attempts that did not become transfers. Neither is a verdict. Both are a queue of streams to open.
tshark -n -r lab.pcapng -q -z conv,tcp
Diagram
From a loud address to the few connections that matter
- Endpoints
Find the address with the surprising packet count. Check the display-filter checkbox.
- Conversations
Open the TCP tab and read bytes in each direction, not just the packet count.
- Filter
Apply one row as a filter and land on its tcp.stream.
ip.addr == 10.8.0.40 && ip.addr == 10.8.0.20
- Note
Quote the count with the filter that produced it.
Check yourself
1. You want each TCP connection as its own row, with bytes in each direction. Which view is that?
2. The packet list is filtered, but Conversations still shows the whole morning. What do you check?
3. Which read-only command prints TCP conversations from a file you already saved?