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

Constructing protocol tree in a Lua dissector only when needed?


I have just written a Lua heuristic dissector (attached to the UDP protocol) which does two things: - updating the Protocol Column - parsing large xml files in order to construct the protocol tree of items to be displayed

I have noticed (and also read on this forum) that the dissector is called several times when loading, displaying and then selecting a packet. As a result, I am facing significant performance issues. I know the dissector could be rewritten in C to be faster but first I would like to know if the following is possible:

When the dissector is invoked by Wireshark, is it possible to know under which circumstances it is called i.e. clicking on a packet or scrolling the packet list, or just loading the pcap file.

The reason I am asking is that the tree only needs to be constructing when the user actually selects a packet. Otherwise, during the initial loading of the file by Wireshark for instance, the only thing that needs to happen is changing the name in the Protocol column which would be very quick.

Is this possible in any way? Or any other alternatives?

This question is marked "community wiki".

asked 20 Feb '15, 12:13

maxvirrozeito's gravatar image

accept rate: 0%

edited 20 Feb '15, 14:53

Guy%20Harris's gravatar image

Guy Harris ♦♦

2 Answers:


The tree only needs to be constructed when the dissector is told to construct a tree; for C dissectors, that's indicated by the tree argument being non-null.

@Hadriel, is there a way to check for that in a Lua dissector?

answered 20 Feb '15, 14:52

Guy%20Harris's gravatar image

Guy Harris ♦♦
accept rate: 19%

I checked the tree argument passed to my Lua dissector and it is never null. So the behaviour is not quite the same as in the C implementation.

As a temporary work-around, I have added a check on pinfo.visited in my Lua dissector which allows to avoid building the tree for the very first pass that Wireshark does on all packets. But there are still too many cases where the tree is built for no purpose, like the second pass for building the packet pane list, scrolling etc.

I do hope there is a way equivalent to your C-implementation description!

(23 Feb '15, 03:34) maxvirrozeito

For better performance, I decided to port the dissector to C.

For a five packet capture, I get: 1/ first dissector pass when Wireshark loads the file: tree = NULL (5 times) 2/ second pass (when Wireshark builds the View List?): tree != NULL (5 times) 3/ one extra pass for the selected packet: tree != NULL (1 time for the selected packet only)

Step 1 and 3 are as expected but why is the tree not NULL for step 2? The tree does not need to be built at that stage yet.

(03 Mar '15, 09:39) maxvirrozeito

Did you have a display or read filter set at the time? If so, the tree is not null in step 1 because the filter needs the fields to be parsed in order to figure out what matches the filter so it knows which packets to put in the view list.

(27 Jun '15, 17:46) Hadriel


So after playing with the example here I found that the real dissection happens only after a call to local fields = { all_field_infos() }, everything above this function is called when Wireshark loads my PCAP file and the whole dissection happens when a tree is to be constructed.
Can anybody explains this behavior?
The function is not documented and the example gives a hint how Wireshark won't make a full dissection at the beginning, but why this function? At the end, we can use this (ugly) solution to improve the load time of the PCAP file

answered 01 Jun '15, 12:39

Amine%20Ahd's gravatar image

Amine Ahd
accept rate: 33%

edited 01 Jun '15, 12:40

It's documented in the Lua API docs, on this page.

The example script uses that function to show what fields there are - it's not a function one would normally use when writing a dissector for a protocol; and the example itself doesn't do any real dissection, it's more of a helper type example to help explain things.

(27 Jun '15, 17:51) Hadriel