Postdissector

What a postdissector does in Wireshark

A postdissector is an analysis layer that runs after Wireshark has already decoded packets. That makes it useful when the meaning of a field depends on context spread across multiple packets, protocols, or sessions rather than on a single frame.

Unlike a normal dissector, which is responsible for parsing protocol structure as packets arrive, a postdissector works on the already populated capture model. It can add derived fields, annotate flows, and expose correlations that are not obvious from a frame-by-frame view.

Why postdissectors exist

Network traffic often contains relationships that only become visible after earlier packets are known, such as sequence, handshake state, request-response pairing, retransmission patterns, or protocol transitions. A postdissector exists to turn those relationships into searchable analysis output.

This is especially valuable in troubleshooting, reverse engineering, and traffic archaeology, where a single packet may look normal but the capture as a whole reveals an issue. The postdissector model lets analysts enrich the packet list without changing the original capture.

How postdissectors change the analysis workflow

Postdissectors do not replace dissectors, they complement them. The first pass interprets the protocol payload, while the postdissector pass can derive higher-level insights from the decoded result and from state accumulated elsewhere in the capture.

That design is useful when you need cross-packet correlation, summary flags, or conditional interpretation that depends on broader context. It also means a postdissector should be kept deterministic and well-scoped, because it is effectively adding a second analytical viewpoint on the same capture.

When to use a postdissector

Use a postdissector when the question you are trying to answer is not “what is inside this packet?” but “what does this packet mean in relation to the rest of the conversation?” Common uses include tagging flows, surfacing hidden protocol state, and deriving indicators that would be cumbersome to inspect manually.

In practice, postdissectors are best suited to enrichment rather than core parsing. If the logic is required just to decode the base protocol correctly, it belongs in a dissector; if the logic is needed to summarize, correlate, or classify already decoded data, a postdissector is the better fit.