PCAP Conversations

When someone hands you a capture with no context, endpoint and pair summaries are the fastest way to work out what it is. Upload a PCAP or PCAPNG and you get the busiest endpoints and the busiest pairs, with packet and byte counts and protocol labels, downloadable as JSON.

An endpoint row answers a different question from a flow row. Endpoints tell you how much a given address did in total, across every conversation it took part in; flows tell you how much one specific conversation carried. Faced with an unfamiliar capture, endpoints come first — fifteen rows usually reveal which handful of machines the capture is really about — and everything after that is drilling in. If you already know the pair you care about, the flow export is the better starting point.

Interpretation is comparative, not absolute. A workstation at the top of the byte list is only interesting if it should not be there: a backup client during the backup window is fine, the same client at 3am on a Sunday is not. Pay attention to shape as much as size. One address dominating bytes usually means a transfer. One address touching a very large number of distinct peers usually means a scan, a proxy, or a mail server. A long tail of addresses with tiny, near-identical counts is generally broadcast and multicast noise — ARP, mDNS, SSDP, NetBIOS — which is worth recognising so you can ignore it.

Pairs give you adjacency: which endpoints spoke to which. This is where segmentation problems become obvious. A user workstation holding direct SMB conversations with twelve other workstations is not how a properly segmented network behaves, and it is a recognised lateral-movement pattern. It is also the quickest way to prove a firewall rule is not doing what the diagram claims, because you can see traffic between two segments that were supposed to be isolated, with counts attached.

The group-by-IP toggle changes the resolution. Leave it on for a machine-level census, where ports are noise — you want to know which hosts are involved, not which ephemeral source port a browser picked. Turn it off when the port is the point: separating a host’s 443 traffic from its 22 traffic, spotting a service listening somewhere nobody approved, or checking whether an application server is hitting a database directly instead of going through the API. Expect a much longer list with grouping off, since client-side ephemeral ports fragment each host into many rows.

Display filters narrow the scope before aggregation, using Wireshark display filter syntax rather than BPF. Common patterns: tcp to drop UDP noise, ip.addr == 192.168.10.0/24 to look at one segment, !(arp || mdns || ssdp) to strip discovery chatter, and not ip.dst == 224.0.0.0/4 to remove multicast. Filtering first also makes the top-N list meaningful, because a handful of loud, uninteresting protocols can otherwise crowd out everything you care about.

The output is JSON rather than CSV because endpoints are a natural input to further work. Addresses feed straight into an ASN or WHOIS lookup, join against an asset inventory by IP, or get diffed between two captures taken before and after a change to see which conversations appeared or disappeared. A flat structure of address, port, protocol, packets and bytes is easy to process with jq or a short script, which is usually faster than repeating the analysis by hand.

Some caveats worth stating plainly. Endpoint totals are only as honest as the capture point: behind NAT or a proxy, every internal host hides behind one address, and a capture taken without a mirror or SPAN port sees a fraction of the segment. Direction in pair rows follows the first packet observed, so a capture that started mid-conversation can label client and server the wrong way round. And no summary tells you what was transferred — it tells you who, how much, and over which protocol. Files are processed to produce the JSON and are not retained.