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

Accessing TreeItem fields in LUA dissector

0

Hello,

I'm writing a LUA dissector, and I have it basically working (the tree shows OK in Wireshark). Now I would like to add into the "Info" column some information that I have already parsed, and that I have already added to my tree.

The problem is that I'm using some ProtoFields in order to extract information from the buffer and to populate my tree. Unfortunately I read that there is no way to use ProtoFields to extract information storing it into locals, and that the only purpose they can be used for is passing them to "add" (or "add_le" in my case) TreeItem's methods.. that is what I'm doing in fact.. (is this right?).

For this reason, I'm wondering whether is there any method to extract information fields from the tree itself (after I got them added to the tree by using "add_le" and the protofield).

Does it ?

I know I could re-parse the buffer and re-extract information without using ProtoField in order to be able to store my information in locals, but indeed what I would like to do is exactly trying to avoid this "duplicated parsing"...

Thanks Andrea

asked 02 May '14, 06:27

Andrea's gravatar image

Andrea
6225
accept rate: 0%

edited 02 May '14, 11:48

Hadriel's gravatar image

Hadriel
2.7k2939


One Answer:

2

Unfortunately I read that there is no way to use ProtoFields to extract information storing it into locals, and that the only purpose they can be used for is passing them to "add" (or "add_le" in my case) TreeItem's methods.

Not true - well... I should say that's not the whole story. A ProtoField is really just metadata about a new field you created for your Protocol, as opposed to using an already existing field. When you pass a ProtoField as an argument into "TreeItem:add()" (or "add_le()"), you're telling Wireshark to use that metadata to extract/parse information from the passed-in TvbRange argument (or to use a raw value if you gave a value argument instead of a TvbRange). The "TreeItem:add()" function does that parsing of the TvbRange, per the info in the ProtoField metadata, and adds the parsed info to the tree, etc.

There is currently only one return value for the "TreeItem:add()" function call, which is a created child subtree. So there isn't any way for your script to get back the parsed info to store in a local variable... not from a function call of "TreeItem:add()". But, the parsed info is added into Wireshark as a real field's data, so you can retrieve it using the normal Field and FieldInfo mechanism, after the call to "TreeItem:add()".

This is in fact done in the tutorial dissector script - the script at the top of the wiki Lua examples page. If you download that script, you'll find there are four Fields which are used to retrieve information from ProtoFields, as follows:

local questions_field       = Field.new("mydns.num_questions")
local query_type_field      = Field.new("mydns.query.type")
local query_class_field     = Field.new("mydns.query.class")
local response_field        = Field.new("mydns.flags.response")

Each of those are later used during dissection, to retrieve the field data previously parsed from "TreeItem:add()" calls with ProtoFields.


I should note that this is slowly changing in release 1.11.4: the "TreeItem:add_packet_field()" function, which is similar to "TreeItem:add()", is being changed to return not only the created child subtree, but also the parsed value. This change isn't complete yet though - it only works for a couple of field types right now (time and bytes fields types).

answered 02 May '14, 11:46

Hadriel's gravatar image

Hadriel
2.7k2939
accept rate: 18%

Thank you for your reply! It seems a nice and clean method to do what I'd like to do. I like it :)

Unfortunately this is not suitable for me, as would like to target stable wireshark releases (1.10.7 right now).. As the comment in the example script suggests, it is not possible to create a Field for a just-registered ProtoField :(

Any workaround or other suggestion while waiting for code in 1.11 to become stable?

Thank you Andrea

(05 May '14, 00:20) Andrea