PCAP Analysis with REA

REA does not capture packets. It reads a pcap or pcapng file you already saved, and it asks a Wireshark 4.x tshark and capinfos that you selected to parse it. There are two families, with different host rules. A finished page of results is not a map of the network.

Reading build metadata from one file, with no external parser, is a different target: inspect a Go binary.

What it does and doesn't do

The summary family, inspect_pcap_capture, inventories addresses, DNS, TLS SNI, protocol stacks, and HTTP URIs. The field family, inspect_packet_capture, returns selected protocol fields, display filters, and decode-as rules. REA chooses the fields and bundles the Evidence. tshark does the parsing. Per the official docs.

Official boundary, verbatim from docs/pcap-analysis.md:

It does not acquire traffic or fetch recorded targets.

The field family states the same limit the other way: it does not acquire traffic, open an interface, or control a device. HAR, SAZ, and mitmproxy workflows stay a separate target. Per docs/packet-captures.md.

Host support matrix

macOS is the cell that gets written wrong. The summary family returns a capability gap there. The field family refuses the host. Neither sentence means "supported on macOS."

Per the official docs, the field family refuses unsupported hosts, including macOS and Windows, because that integration requires an enforced address-space limit.

Tool paths are REA_TSHARK_COMMAND, REA_CAPINFOS_COMMAND, and REA_TSHARK_PRLIMIT_COMMAND. Without those, the summary family resolves the tools through PATH and records the selection source. Per the official docs.

export REA_TSHARK_COMMAND=/absolute/path/tshark
export REA_CAPINFOS_COMMAND=/absolute/path/capinfos
export REA_TSHARK_PRLIMIT_COMMAND=/absolute/path/prlimit
rea inspect-pcap-capture /captures/session.pcapng --json

(The commands above are per the official docs/pcap-analysis.md. This site has not run them.)

Resource and time budget chain

One inspection is admitted at a time per provider. A concurrent call returns a capacity error. Close drains active work before the slot is released. Per the official docs. The two families do not share one budget.

Field family, per docs/packet-captures.md:

• Input is limited to 32 MiB before reading.
• Each command is limited to 30 seconds.
• Combined stdout and stderr are limited to 4 MiB during collection. Overflow fails. It does not return a truncated success.
• Before execution, prlimit enforces 1 GiB of address space per process, 64 MiB per file, 30 CPU seconds, and no core dumps.

Summary family, per docs/pcap-analysis.md:

• The capture is streamed into a read-only owned snapshot with a 2 GiB disk budget.
• Command wall deadlines are 300 seconds for dissection, 60 seconds for metadata, and 20 seconds for probes.
• TShark output is bounded at 8 MiB. Capinfos output is limited to 64 KiB.
• On Linux, native capture commands enforce an address-space ceiling of at most 1 GiB, 300 CPU seconds, 64 MiB per file, and no core dumps. Windows uses a 1 GiB committed-memory limit for each owned tool tree.

Those ceilings are not an aggregate machine quota or a filesystem quota. Per the official docs.

Pagination and facets

Summary views default to offset 0 and limit 64. The documented row facets are endpoints, dns-queries, dns-addresses, tls-sni, protocols, http-uris, and unattributed-addresses. There is no stream or session facet. Per the official docs.

How to read a row, still per the official docs:

• Addresses count once per packet, including loopback and nested IP occurrences.
• DNS addresses are associated only with one question in the same response packet. Additional records may be included, so this does not prove final resolution.
• TLS SNI is recorded handshake metadata. It is not process identity, and it is not proof the destination is authentic.
• HTTP transport credentials are excluded from URIs. Other URI bytes are not rewritten. An ambiguous credential span causes the URI to be omitted.
• In the field family, each call checks the recording's current digest. Pages from different source digests must not be combined.

What you cannot infer

The field family does not reassemble a TCP session for you. Two-pass mode is on by default for fields that need later packets. Two-pass mode cannot recover bytes the capture never stored. Per the official docs.

An empty result does not prove the traffic was absent outside the selected recording, filter, or read range. Per the official docs.

packet_limit is the maximum number of input packets read before filtering. A limit of 1 can yield zero matching packets even when a later frame would have matched. The report says to-eof or up-to-input-packet-limit. It does not infer the capture's total size from the row count. Per the official docs.

A display filter of frame.number <= 2000, without an input limit, still reads the entire capture. Returning twelve rows does not limit what tshark produced. Per the official docs.

No payload bytes are added automatically. Select a byte field such as data.data or @data when you need them. Per the official docs.

Installed libraries, global configuration, and plugins stay caller-trusted. They are not fully fingerprinted, and they can change dissection. The same file can yield different fields on two machines. An empty private Wireshark configuration is used. That is not an OS sandbox. Per the official docs.

Page exhaustion ≠ complete network map

When a summary page is exhausted, you have covered the retained facet. You have not established that the network is complete, and you have not recovered traffic the capture missed. Per the official docs:

Page exhaustion covers the retained facet; it does not establish network completeness or recover missing traffic.

Malformed or oversized output returns no partial success. Unvalidated partial JSON is not returned as facts. If cleanup fails, the summary family returns a typed error, keeps completed Evidence when it has it, and keeps the owned resources so a later close can retry. Per the official docs.

Verification scope

Per docs/pcap-analysis.md, current follow-up verification uses Linux, Node 24.18.0, and Wireshark 4.0.17. An earlier report of Linux with Wireshark 4.6.6, and macOS or Windows with 4.6.9, does not verify the new memory boundary. Actual Windows and Bun Wireshark execution is unverified there. macOS capture support needs a separate decision about an enforceable bound.

npm run verify:pcap is the project's verifier. Without --pcap, capture inspection is reported as unverified. This site has not run it.

Related

The other built-in file read, with no tshark and no capture at all, is inspect a Go binary.

Last verified: 2026-10-18 · REA 6.6.0 (tag rea-agents-6.6.0) · docs unchanged at 6.7.0 (tag rea-agents-6.7.0) · fields quoted per the official docs/pcap-analysis.md.