Comment # 17
on bug 6020
from Hadriel Kaplan
I was curious why it was inconsistent, so I put in a bunch of printf's and
found it.
As I said in my previous comment, Lua-based field extractors generate a fake
tap and fake dfilter. In other words the proto_tree is primed with their
hfid's header_field_info ref_type = HF_REF_TYPE_DIRECT, when the tap dfilter is
used/primed for each packet. That only happens on the first pass of packets,
because taps only get used in that pass. It also happens when a specific
packet/row is selected, because the tap dfilters are used then as well. This
means Lua-based field extractors are only usable fully in that first pass,
whether in a listener or post-dissector; and when a packet is selected, but
then only in a post-dissector. And in neither case can one set column info -
that's done in the second pass.
The reason some but not all Lua field extractors are accessible during the
second pass is just based on a coincidence. During the second pass the
proto_tree is primed with the color filters, so that any field in the color
filters is extracted and thus Lua can see it. So if you use a Lua field that
happens to be in the color filters, Lua will see it in the second pass and can
set/get column info based on it.
The reason the test scripts attached to this bug were able to set the column
info for one row but not others is a bit complicated, and only happens when
wireshark first starts up and loads its first file. Files opened afterwards
won't exhibit this behavior it appears.
The long explanation is:
When the file is loaded it walks through all the packets (the first pass) as
described previously. If this is the first file loaded since wireshark app was
started, then GTK calls packet_list_select_cb() which calls cf_select_packet()
on the first packet *before* GTK's GtkTreeView widget walks the packet list
getting values. cf_select_packet() calls tap_build_interesting(), which primes
the packet_tree based on registered taps (which Lua created a fake one of).
That's similar to the first pass, except taps aren't actually called/executed
when a packet is selected, and more importantly in this case the primed tree
from the dfilter is not cleared when cf_select_packet() is done. Thus the
ref_type for the tap's hfid's are still HF_REF_TYPE_DIRECT at this point.
Now GTK starts grabbing the values for its GtkTreeView using the
packet_list_get_value() function, which calls
packet_list_dissect_and_cache_record() to dissect another packet/frame, during
which those tap's hfids will be populated (along with ones for color filters).
Therefore the Lua fields are extracted for this "initial" packet in the list,
but this initial packet is not packet #1 as explained later. Since
packet_list_dissect_and_cache_record() calls epan_dissect_cleanup() at its end,
after this initial packet the tap's hfid's are reset and subsequent GTK calls
to packet_list_get_value() for other packets won't populate them.
What's odd is GTK is calling packet_list_get_value() for this initial
packet/row for some *other* packet than packet #1, when it's the first time
wireshark opens a file form starting up. It appears to choose the one based on
the size of the file or display window or something. When opening subsequent
files, however, GTK is calling packet_list_get_value() in order from packet #1,
and it calls cf_select_packet() after it's done with getting the full list of
values, instead of before getting it as it did when it loads the first time.
So in summary, after the first pass, packet #1 will populate the Lua fields
because it's "selected" and thus fills in everything, and then the first packet
chosen by GTK to populate the widget (which is basically some random packet in
the list) will also populate the Lua fields because packet #1 didn't clear the
dfilter; but then no other packets will populate the Lua fields unless those
fields happen to be interesting for some other reason, e.g. they're in a color
filter.
You are receiving this mail because:
- You are the assignee for the bug.
- You are watching all bug changes.
