How a frame is processed#

Packet Capture turns a live interface or a saved capture file into a workspace. The workspace gives you a packet list, a layered decode for every frame, a network graph of endpoints, and charts driven by any column. This page follows a single frame from the moment it hits the wire to the moment it appears in the views you work with. You can then predict how the workspace behaves on your traffic.

The capture pipeline#

Every frame moves through the same stages, whether it arrives on your interface or comes from a pcap file. Each stage feeds the next. The workspace becomes interactive as soon as the first frames arrive.

Each arrow is one-way. Packet Capture never alters the bytes on the wire. It never modifies a capture file on disk when you open it.

Two sources of frames#

Packet Capture works from two sources:

• A live interface. Select an interface in the toolbar, then select Start. The workspace records every frame the interface sees. The packet count next to the toolbar updates as frames arrive.
• A saved pcap file. Open a .pcap, .pcapng, or .cap file from disk through the settings menu. Large files stream in instead of a single load, so you can search and filter while the workspace still reads the rest of the file.

Both paths end up in the same pipeline and the same workspace views. You can keep more than one capture open at the same time. Each tab owns its own frames, filters, and chart settings, and the tabs do not share state.

Note Stopping a live capture does not clear the workspace. The frames already recorded stay loaded so you can keep investigating.

How layers are decoded#

When a frame arrives, Packet Capture decodes it layer by layer, from the lowest layer up. At each layer it reads the header, records the fields you can see in the Layered View, and hands the remaining bytes to the next layer.

The detail pane shows these typical layers, which map to the stages above:

A decoder only runs when the layer below points at it. For example, the TLS decoder only runs on TCP segments whose port or handshake bytes look like TLS. Frames the workspace cannot identify still appear in the list with their lower layers decoded; only the application layer stays unnamed.

Reassembling TCP streams#

Many application-layer messages do not fit in a single TCP segment. The network can split a TLS certificate chain, an HTTP/2 frame, or a long HTTP/1 response body across many segments. Those segments can arrive out of order, or arrive again as retransmissions. Packet Capture reconstructs the original byte stream before it hands the bytes to the application-layer decoder.

For every TCP conversation in the capture, the workspace:

1. Groups segments by the four endpoints of the connection (source address, source port, destination address, destination port) and assigns the conversation a Stream ID you can see in the packet list.
2. Buffers segments per direction in sequence-number order, so the client-to-server and server-to-client byte streams are kept separate.
3. Drops exact duplicates (retransmissions) and holds out-of-order segments until the missing piece arrives.
4. Feeds the assembled byte stream to the application-layer decoder, so a TLS handshake split across five segments still resolves to a single handshake record.

Each stream has a per-direction buffer cap, so a very long-lived connection cannot grow without bound. When a stream reaches the cap, the workspace drops older segments in favour of newer ones and keeps running.

Note The Sequence view in the detail pane is driven by this same reassembly. Arrows between endpoints are the segments the workspace grouped into the current conversation.

Building the session index#

After the decode, and the reassembly where it applies, the workspace records each frame into an in-session index. Every view in the workspace reads from the same index:

• The packet list reads rows in arrival order, one per frame.
• The filter bar compiles each expression once and evaluates it against the indexed rows, so the list updates live as you type.
• The network graph and connection table read endpoint and conversation counts straight out of the index.
• The timeline reads per-endpoint activity bands and a capture-wide packet histogram.
• The charts read numerical columns (length, port, stream ID, and so on) keyed by time.

The index lives only for the life of the tab. When you close the tab, the workspace discards the index. It uploads nothing and synchronises nothing. Every decoded field, every stream, and every computed statistic stays on your machine.

Feeding the workspace views#

The same indexed frames drive every view you switch between. A filter you apply in one view therefore narrows the others.

A filter or a payload search does not make a copy of the capture. It narrows the set of frame IDs the views can see. When you clear the filter, every row returns and nothing reloads.

What an export writes#

You can save a capture in the workspace back out to a standard .pcap file that other network tools can read. The export writes the original frame bytes, not the decoded view. Nothing the workspace inferred (stream IDs, application-layer parses, statistics) goes into the exported file. When you open that file again, it runs through the same pipeline and the workspace rebuilds the index from scratch.

You can export every frame, or open Export Options from the settings menu to select a range of packet IDs. See Overview for where these options live in the toolbar.

What this means for your captures#

A few consequences follow from the pipeline above:

• Long captures are fine. Frames stream into the index as they arrive, so the workspace stays interactive throughout a multi-hour capture.
• Large pcap files open directly. The workspace streams a capture file instead of a single load, and you can start work before the import finishes.
• Split application messages still decode. Reassembly shows a TLS handshake or an HTTP/2 frame spread across many TCP segments as a single, readable message in the layered view.
• Filters and searches are live. Every view shares the same index, so a filter typed into the bar narrows the list, the graph, the timeline, and the charts together.
• Your traffic stays local. The decode, the reassembly, the index, and every view run on your machine. When you close the tab, the workspace discards the capture from memory.