Wireshark-bugs: [Wireshark-bugs] [Bug 6020] Lua pinfo.cols.protocol not holding value in postdis
Date: Wed, 13 Feb 2013 00:24:58 +0000
Hadriel Kaplan changed bug 6020
What | Removed | Added |
---|---|---|
CC | [email protected] |
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.
- Prev by Date: [Wireshark-bugs] [Bug 8324] VoIP Call Flow dialog does not fully update on interaction
- Next by Date: [Wireshark-bugs] [Bug 8319] CAPWAP Header dissector returns invalid length
- Previous by thread: [Wireshark-bugs] [Bug 8325] Registering ieee802154 dissector for IEEE802.15.4 frames inside Linux SLL frames
- Next by thread: [Wireshark-bugs] [Bug 6020] Lua pinfo.cols.protocol not holding value in postdissector
- Index(es):