Wireshark-bugs: [Wireshark-bugs] [Bug 6357] Lua scripting: all_field_infos() broken within tap/l

Date: Sun, 17 Feb 2013 21:59:15 +0000

Comment # 4 on bug 6357 from
I'm not sure in which way you mean that question.  It doesn't require they be
"visible" in the literal sense of visible through the GUI, but Lua can only
access field_info's from the proto_tree if the field_info is actually
created/populated, of course.  Since they're usually *not* populated, and only
fully populated when the tree is "visible" (in the GUI sense), then I suppose
you could say Lua can only use visible ones.  

Well, at least for this all_field_infos() type function anyway.  They don't
have to be visible when Lua accesses field_info's by using a field extractor
(i.e., through "Field.new()").  In that case the field is populated because Lua
creates a fake tap and dfilter to force it to be populated, even though it's
not "visible".  But that only works when you know the particular field(s) you
want to access, which is not what the all_field_infos() is used for.[1]

Background:
The current API for Lua provides a global[2] function "all_field_infos()" which
returns all the populated field_info nodes in the current proto_tree. 

By default all_field_infos() "works", in the literal sense: it returns exactly
the fields the previous dissectors of the packet have populated at that instant
of time.  But of course dissectors don't populate all the applicable fields
most of the time, because of the TRY_TO_FAKE_THIS_ITEM optimization where they
don't fill in things that aren't needed at the time by a display, color, or
tap's dfilter.

So my attached patch offers a way to force the dissectors to populate all the
applicable field_infos in the tree, by setting the proto_tree to be visible. 
Obviously that is going to impact performance, since it basically bypasses the
TRY_TO_FAKE_THIS_ITEM optimization; so the patch only does this if the Lua
script author told it to explicitly, as described in a previous comment.

[1] It works except for bug 6020.
[2] I say "global" because it's in Lua's global table, but in fact can only be
called/used in a Listener or Dissector.  If we were able to deprecate Lua
functions, I'd argue this shouldn't be a global, but should instead be a member
function of the Lua Listener and Dissector classes.


You are receiving this mail because:
  • You are watching all bug changes.