Revision history [back]

A "normal" dissector is invoked to deal with a given layer of the protocol stack present in the packet after eventual dissection of lower layers has been done, and it invokes another dissector to deal with the payload part of its layer. A practical example is that Ethernet dissector invokes IP dissector which invokes TCP dissector which invokes HTTP dissector. Due to this order, the dissection tree is filled with information in the order of protocol layers: ethernet ipv4 tcp http

A post-dissector is invoked after all the "normal" dissector have done their job, so its output can only appear at the bottom of the dissection tree.

A tap collects information from several packets as they are processed by other dissectors, in order to provide some summary information, not in a dissection tree of a single packet but in some own output window (e.g., to display the number of packets of various types captured so far during capture is an illustrative task for a tap).

To answer your real question: your approach of maintaining a global table is correct, but your observation that dissectors are called several times is also correct, and you have to match the approach to that fact.

When you open the capture file for the first time, or whenever you change the display filter, all packets are dissected in sequence. Whenever you click an individual packet in the list, it is dissected again to display the contents in the dissection pane. And when you click a packet during a live capture, it even breaks the rule that for the first time all packets are dissected in sequence.

There is a pinfo.visited value, but in the past I've noticed doubts whether it works correctly, so when I deal with tasks like yours, I always build my own table to note down whether this particular packet has already been dissected once or not. This addresses even the situation where you click a packet during live capture.

A "normal" dissector is invoked to deal with a given layer of the protocol stack present in the packet after eventual dissection of lower layers has been done, and it eventually invokes another dissector to deal with the payload part of its layer. A practical example is that Ethernet dissector invokes IP dissector which invokes TCP dissector which invokes HTTP dissector. Due to this order, the dissection tree is filled with information in the order of protocol layers: ethernet ipv4 tcp http

A post-dissector is invoked after all the "normal" dissector have done their job, so its output can only appear at the bottom of the dissection tree.

A tap collects information from several packets as they are processed by other dissectors, in order to provide some summary information, not in a dissection tree of a single packet but in some own output window (e.g., to display the number of packets of various types captured so far during capture is an illustrative task for a tap).

To answer your real question: your approach of maintaining a global table is correct, but your observation that dissectors are called several times is also correct, and you have to match the approach to that fact.

When you open the capture file for the first time, or whenever you change the display filter, all packets are dissected in sequence. Whenever you click an individual packet in the list, it is dissected again to display the contents in the dissection pane. And when you click a packet during a live capture, it even breaks the rule that for the first time all packets are dissected in sequence.

There is a pinfo.visited value, but in the past I've noticed doubts whether it works correctly, so when I deal with tasks like yours, I always build my own table to note down whether this particular packet has already been dissected once or not. This addresses even the situation where you click a packet during live capture.

A "normal" dissector is invoked to deal with a given layer of the protocol stack present in the packet after eventual dissection of lower layers has been done, and it eventually invokes another dissector to deal with the payload part of its layer. A practical example is that Ethernet dissector invokes IP dissector which invokes TCP dissector which invokes HTTP dissector. Due to this order, the dissection tree is filled with information in the order of protocol layers: ethernet ipv4 tcp http

A post-dissector is invoked after all the "normal" dissector dissectors have done their job, so its output can only appear at the bottom of the dissection tree.

A tap collects information from several packets as they are processed by other dissectors, in order to provide some summary information, not in a dissection tree of a single packet but in some own output window (e.g., to display the number of packets of various types captured so far during capture is an illustrative task for a tap).

To answer your real question: your approach of maintaining a global table is correct, but your observation that dissectors are called several times is also correct, and you have to match the approach to that fact.

When you open the capture file for the first time, or whenever you change the display filter, all packets are dissected in sequence. Whenever you click an individual packet in the list, it is dissected again to display the contents in the dissection pane. And when you click a packet during a live capture, it even breaks the rule that for the first time all packets are dissected in sequence.

There is a pinfo.visited value, but in the past I've noticed doubts whether it works correctly, so when I deal with tasks like yours, I always build my own table to note down whether this particular packet has already been dissected once or not. This addresses even the situation where you click a packet during live capture.

A "normal" dissector is invoked to deal with a given layer of the protocol stack present in the packet after eventual dissection of lower layers has been done, and it eventually invokes another dissector to deal with the payload part of its layer. A practical example is that Ethernet dissector invokes IP dissector which invokes TCP dissector which invokes HTTP dissector. Due to this order, the dissection tree is filled with information in the order of protocol layers: ethernet ipv4 tcp http

A post-dissector is invoked after all the "normal" dissectors have done their job, so its output can only appear at the bottom of the dissection tree.

A tap collects information from several packets as they are processed by other dissectors, in order to provide some summary information, not in a dissection tree of a single packet but in some own output window (e.g., to display the number of packets of various types captured so far during capture is an illustrative task for a tap).

To answer your real question: your approach of maintaining a global table is correct, but your observation that dissectors are called several times is also correct, and you have to match the approach to that fact.

When you open the capture file for the first time, or whenever you change the display filter, all packets are dissected in sequence. Whenever you click an individual packet in the list, it is dissected again to display the contents in the dissection pane. And when you click clicking a packet during a live capture, it capture even breaks the rule that for the first time time, all packets are dissected in sequence.

There is a pinfo.visited pinfo.visited value, but in the past I've noticed doubts whether it works correctly, so when I deal with tasks like yours, I always build my own table to note down whether this particular packet has already been dissected once or not. This addresses even the situation where you click a packet during live capture.