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

Lua/C++ Dissector Types

Hello!

I am prototyping a dissector in Lua, after the dissector is done I'll convert it to C++.

The goal of the dissector is to dissect data from Ethercat packets for a company specific application. However, when I run my dissector it takes the place of the ECAT dissector (the built-in EtherCat dissector in Wireshark).

I would like for my dissector to follow after the ECAT dissector, not take its place. My current understanding is:

POST DISSECTOR: This will make my dissector be called after every packet, regardless of whether or not the packet is of Ethercat type. I cannot have my dissector behave this way.
CHAINED DISSECTOR: This will take over the place of an existing dissector.
HEURISTIC DISSECTOR: This will simply send "specific" packets to my dissector, but will still take the place of an existing dissector.

Is there a dissector type I am missing, or do I have misunderstanding of the dissector types listed above?

chained-dissector lua dissector heuristics

asked 01 Nov '16, 14:04

Irfan Hossain
11●6●6●11
accept rate: 0%

edited 03 Nov '16, 09:24

One Answer:

The "chained dissector" and "heuristic dissector" are quite orthogonal terms.

When a dissector of a given layer (e.g., UDP) has finished processing its header fields and decides which dissector to invoke for the payload, it has several paths to take:

first, to check whether the packet is not part of an already established conversation - if it is, it invokes a dissector previously associated to that conversation. A conversation key consists of source and destination addresses and ports.
to consult a dissector table which maps the port number (in case of UDP) or some other number or string obtained during dissection of the header fields to a pointer to a dissector to be invoked
to offer the payload to all the heuristic dissectors registered to it as potential sub-dissectors, one by one, until one of them reports success or all have been tried in vain. Each of the heuristic dissectors makes a quick analysis of the offered data and if it can dissect them without errors, it does so and returns back success (a non-zero value representing the size of the part of the TVB which it managed to dissect) so that the invoking dissector knows that the data have been dissected successfully. Where meaningful, it may also register a conversation.

In some cases, the order of the last two steps can be chosen in the invoking dissector's preferences (Try Heuristic Dissectors First).

Chaining dissectors is another thing. For your purpose, you can store a pointer to the default dissector for a given key value in a dissector table, register your own dissector to the table for that key, and then your dissector may first call the default dissector and then do its own dissection of the same data. That way, you'll have the results of the default dissector (including all dissectors it eventually invokes!) in the dissection tree first, followed by those provided by your dissector. So in many cases the result may be the same as if you used a post-dissector, so maybe you should specify what exactly you expect from running the original dissector first. Maybe swapping the order (first yours, then, if necessary, the default one) would match your goal better?

Also, there is no default Lua dissector. You can replace a C dissector by a Lua one, and sub-dissectors invoked by a Lua dissector may be C dissectors again.

answered 02 Nov '16, 02:26

sindy
6.0k●4●8●51
accept rate: 24%

edited 02 Nov '16, 10:01

Thank you so much for the thorough explanation and suggestions! This has definitely helped increase my understanding of how dissectors are invoked.

Also, I made a mistake in my paragraph, I meant to say Wireshark instead of Lua, I'll fix that.

Thanks again!

(03 Nov '16, 08:57) Irfan Hossain

I should specify that I want the default Ethercat Dissector to run in its entirety. Then I would like my dissector to analyze the data in the datagrams.

(03 Nov '16, 09:29) Irfan Hossain

I'm not sure I get you right as I'm not familiar with EtherCAT, but:

to post-process the fields already dissected by the default Ethercat dissector, there is little difference between using your own dissector as a post-dissector and registering it instead of the default one and letting it invoke the default one as the first thing to do. In both cases, the fields contributed by your dissector will be added to the dissection tree after (below) the fields contributed by the default dissector.
if your proprietary protocol is actually a particular type of payload of Ethercat, i.e. if you actually want to process those pieces of EtherCAT payload which the default dissector cannot handle, the default dissector provides a hook for heuristic dissectors called ecat.data exactly for this purpose. So if you create a dissector function which can identify and dissect the payload of your proprietary protocol yourproto, called heur_yourproto, you can register it as a heuristic sub-dissector of Ethercat as follows:
yourproto:register_heuristic("ecat.data",heur_yourproto)
That way, your dissector will be called with only the relevant payload as the tvb parameter, and the fields contributed by your dissector will be placed at the proper place in the hierarchy of the dissection tree. And, as described above, if your dissector concludes that the data it got do not belong to it, it simply returns 0 and the Ethercat dissector knows that it has to place just data as a hex field into the tree (unless another heuristic dissector is registered next to yours).

(03 Nov '16, 11:01) sindy