Hello, I have a listener that needs to get field value dynamically. Since Field_new can only be used outside of a tap I tried using all_field_infos() which does work like this: fields = { all_field_infos() } This gives me an array of field_info objects of the upper most protocols in the tree, the problem is I can't figure out how to walk over the branches. Seems like this function lacks documentation, or is not really meant to be used. asked 22 Jun '11, 13:53  Demon retagged 23 Jun '11, 19:49  helloworld |
2 Answers:
I don't think it's a bug - it's by design. And it happens for both Listeners and Dissectors. The problem is packets aren't fully dissected - or rather their field trees aren't created - until you select a packet. So when a tap Listener is called in Lua, the proto tree hasn't been fully created; and likewise for when a dissector is called. It just happens that a dissector will be called multiple times, including when the user selects a packet and thus when the full tree is available. I've added an example script to show this happening, titled "View Packet Tree of Fields/FieldInfo" in here: http://wiki.wireshark.org/Lua/Examples answered 12 Feb '13, 08:45  Hadriel For a dissector (no matter what language it's in), there are no guarantees that the full tree is built, nor should there be. For taps and post-dissectors (which I consider to be different from dissectors; dissectors just analyze a particular protocol's packets, post-dissectors do, well, post-dissection processing of the packet summary or detail information), a way to request that particular fields be made available, or that all fields be made available, should be added if it's not already present. (12 Feb '13, 15:13) Guy Harris ♦♦ [replying to Guy's comment] If you use a field extractor (ie, use Field.new() and so on), then the tap/post-dissector will get that particular field(s) with a call to But it's definitely not the case that a tap or a post-dissector will get "all" the fields - it will get all the fields that the dissectors happened to fill, which for listener taps case is virtually none; and for post-dissectors is hit-or-miss. I agree it should be otherwise. One way to fix this is to make the tap/post-dissector registration have a flag similar to (12 Feb '13, 22:10) Hadriel |
A patch to solve this has been attached to bug 6357. answered 17 Feb '13, 07:47 Hadriel |
It turns out that
all_field_infos()behaves differently in a tap/listener than a postdissector. The function correctly enumerates all fields in the postdissector while it only includes the header fields in the tap. This is likely a bug.Weird. Did you open a bug report, or should I?
No, I haven't opened a bug for it (you can do it).
I will soon. Thank you for your time.