Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 6020] Lua pinfo.cols.protocol not holding value in postdissector

[bugzilla-daemon@xxxxxxxxxxxxx]

Hadriel Kaplan changed bug 6020

What	Removed	Added
CC		hadrielk@yahoo.com

Comment # 15 on bug 6020 from Hadriel Kaplan

I know this is an old bug, but it's still true in v1.9.0 so I thought I'd
explain it, because I think I know the cause.  Basically it's the confluence of
two things at once: proto_tree usage and column_info usage.  

Both the original g2s.lua and the 'trivial' lua scripts use a field extractor -
the thing they call Field.new() for.  They use it to get either the "xml.cdata"
or "tcp.src" fields for use later in their dissectors.  If those Fields are
nil/empty in the dissection routine, then they don't set the protocol column
text; and they only try to set the proto column text if the Field resolves to
something.  And that's the problem: dissectors are run multiple times,
sometimes with the protocol fields filled-in but without access to setting
columns, and other times with access to setting column text but without the
protocol fields filled-in.

Under the hood, a Field is useful only if the protocol tree (proto_tree) is
filled in for that packet, as that's literally where the Field's data comes
from.  When wireshark first loads a file it seems to scan all the packets and
fills in the protocol tree of each packet, and then scans them all a second
time setting column text but not filling in the protocol tree; and when you
select a particular packet later, it re-dissects the packet for the purpose of
filling in the protocol tree (to display it in the middle window pane), but
without giving access to set column text.  This logic makes some sense, since
filling in the protocol tree is a waste of time for anything but the selected
packet, whereas selecting a particular packet shouldn't modify the column texts
at that point.  Although why it does the initial scan of filling in protocol
tree without providing access to column text is beyond me. (maybe to trigger
taps?)

So anyway, in the case of these problem scripts, when their dissectors first
run for a given packet the Field getter is good but there's no column setter
access (cinfo is NULL); and on the second pass the Field getter resolves to nil
and thus they don't set the column text; and when a packet is selected the
Field getter again works but not for changing column text.  Moving the column
text setter function before the if...then statements "fixes" it because of
this, since it no longer relies on the Field resolving to anything.

I guess the big question is whether this should be "fixed"/gracefully-handled
somehow or not.  Arguably it is counter-intuitive that a Field isn't valid just
because this particular pass of the dissection doesn't care about the tree for
normal C-code use, when Lua-code actually needs it.  We could have a flag that
forces the C-code dissectors to fill-in the protocol tree if and only if the
Lua callback demands it - i.e., have a new argument for
register_postdissector() function such that if true, then C-side code performs
a full protocol tree dissection before calling the registered post-dissector.
(i.e., similar to how TL_REQUIRES_COLUMNS makes the column info available to
taps if any of them set it)

---

      You are receiving this mail because:

• You are the assignee for the bug.
• You are watching all bug changes.