This is our old Q&A Site. Please post any new questions and answers at


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's gravatar image

accept rate: 0%

retagged 23 Jun '11, 19:49

helloworld's gravatar image


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.

(18 Jul '11, 07:55) helloworld

Weird. Did you open a bug report, or should I?

(15 Aug '11, 08:20) Demon

No, I haven't opened a bug for it (you can do it).

(16 Aug '11, 23:19) helloworld

I will soon. Thank you for your time.

(18 Aug '11, 01:32) Demon

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:

permanent link

answered 12 Feb '13, 08:45

Hadriel's gravatar image

accept rate: 18%

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 and so on), then the tap/post-dissector will get that particular field(s) with a call to all_field_infos(), because the underlying code does a hack by creating a fake tap with a fake dfilter to make it so. Well... it works except for bug 6020.

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 TL_REQUIRES_COLUMNS, to force tree population. I.e., make both the Lua script author set such a flag, and make the C-side code use it for this purpose. That way it doesn't impact performance for anyone not needing it.

(12 Feb '13, 22:10) Hadriel

A patch to solve this has been attached to bug 6357.

permanent link

answered 17 Feb '13, 07:47

Hadriel's gravatar image

accept rate: 18%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 22 Jun '11, 13:53

question was seen: 5,580 times

last updated: 17 Feb '13, 07:47

p​o​w​e​r​e​d by O​S​Q​A