Ask Your Question

LUA: avoid auto-expand sub-tree

asked 2021-08-05 16:56:55 +0000

sezb51 gravatar image


my LUA dissector has a general header followed by an arbitrary number of tlv sections. Each tlv section has its own header (len / type) followed by the tlv-data.

Currently I just iterate across each tlv reusing the same protofield to make the proper decoding (ascii vs hex vs ...) = ProtoField.bytes ("", "Data Hex")

Everything is fine except when I select a byte sequence in the wireshark's raw data (at bottom). When that happens wireshark correctly expand the specific tlv but as soon as I move to a different packet (of same dissector) then all tlv get auto-expanded and it take some time to manually close one by one.

I suspect this is because of the reuse of same ProtoField during the walk-in iteration.

How can I make use to use different protofield each time (maybe tying it to the tlv type) ? Otherwise is there any way to programmatically collapse such trees when inspecting a new packet ?


edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2021-08-05 17:30:41 +0000

cmaynard gravatar image

I suspect this is because of the reuse of same ProtoField during the walk-in iteration.

Yes, that's the reason.

Otherwise is there any way to programmatically collapse such trees when inspecting a new packet ?

You can use "View -> Collapse All" to collapse all trees, or the equivalent keyboard shortcut combination, Ctrl+Left (i.e., the Ctrl and Left Arrow keys).

edit flag offensive delete link more


I agree there is a collapse all menu but that requires user action each time and I do prefer to avoid it if possible.

Is there any way to define runtime protofield where I add the tlv type number as differentiation ? That normally works well in javascript in orfer to add unique id elements to the html DOM tree. Now not sure if LUA has some way to implement it…


sezb51 gravatar imagesezb51 ( 2021-08-05 18:09:42 +0000 )edit

I don't know how many different TLV types you have to be concerned with, but if it's not a large number, you could declare a unique ProtoField for each of them.

Unfortunately, that normally also means defining unique display filters for each of them as well; otherwise you'll get warnings/errors about duplicate display filters. I write normally because that's what would happen if you wrote a C dissector, but apparently Wireshark doesn't complain for duplicated display filters in Lua dissectors ... at least not yet it doesn't. So at least for now that might actually be an option for you.

cmaynard gravatar imagecmaynard ( 2021-08-05 18:48:30 +0000 )edit

You making a good point when you mention possible display filter clash for specific tlv.

Currently we have around twenty-ish different tlv …

So it will have to be a messy nested “if then else” (no switch available in LUA) but from positive side it give you more control on which data to display on each tlv…

I guess the issue would reappear for the unknown tlv … though these should not happen if not in the spec…


sezb51 gravatar imagesezb51 ( 2021-08-05 19:11:28 +0000 )edit

It doesn't necessarily have to be a messy nested "if then else"; you could grab the type from the TLV then use it to add the corresponding ProtoField from a table. If the lookup is nil, then you could just use a default ProtoField for all unknown/unsupported TLVs.

cmaynard gravatar imagecmaynard ( 2021-08-05 19:24:10 +0000 )edit

so a table with tlv type as index that contains ProtoField variable ? I need to try up some code :)

sezb51 gravatar imagesezb51 ( 2021-08-05 19:28:38 +0000 )edit

Yes, either that or a table of functions per TLV type and within each function, the appropriate ProtoField would be used.

cmaynard gravatar imagecmaynard ( 2021-08-05 19:41:03 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2021-08-05 16:56:55 +0000

Seen: 67 times

Last updated: Aug 05