This is a static archive of our old Q&A Site. Please post any new questions and answers at

Why does Wireshark make multiple passes during dissection?


Wireshark makes multiple passes over captured packets during dissection. I have read the various doc/README.*s, and I it my understanding that the first pass is made without constructing protocol trees (the tree argument to each dissect_PROTONAME function is NULL), and that the second pass is made to construct the protocol trees. Are these the only two passes made, or are there more? Additionally, what is each pass supposed to accomplish, since the same dissection functions are called each time?

tl;dr: What are the different passes over packets during dissection for?

asked 09 Nov '11, 15:21

multipleinterfaces's gravatar image

accept rate: 12%

One Answer:


When a capture file is read in, Wireshark processes every packet. Whether the protocol tree is constructed or not depends on the version of Wireshark and on whether the protocol tree happens to be required for some reason when reading in the capture. Whether that's the case depends on a number of things, which I don't happen to know of offhand; no dissector or user should make assumptions about whether the protocol tree will be constructed on the first pass, as that's subject to change from release to release without notice.

The packets whose summaries are on the screen will probably be redissected to generate some of the columns, such as the Info column; scrolling the packet list will probably cause the packets that appear on the screen to be redissected. Currently, the value of the column will be saved after it's created the first time, so they won't be redissected merely to generate those columns, but that is also subject to change in the future.

If you then click on a packet, the packet is redissected, in order to generate the protocol tree; saving dissected protocol trees for all packets would consume a huge amount of memory. This is not a "pass", as there is no guarantee that the redissections will happen in sequential order.

Various operations, such as calculating various statistics, filtering the display, printing the packets, etc. will cause the packets to be redissected to generate the columns or the protocol tree.

Changing protocol preferences will also cause a complete redissection, as changing them could change the way the packets are dissected.

Each dissection is supposed to accomplish as much as is necessary and as little as is possible. :-) I.e., it needs to generate something, even if it's internal state required to dissect later packets or even the current packet if it's revisited. However, the less it generates, the less time it takes, so we try not to generate stuff we don't need.

answered 09 Nov '11, 16:43

Guy%20Harris's gravatar image

Guy Harris ♦♦
accept rate: 19%

Is there any Doc/link for understanding it better ?. Comments in core are not sufficient to understand the architecture of dissector and its interaction called from Filter/Line Summary.

(24 Aug '12, 04:40) Harsha