[Lua] Bad argument #1 to Field.new (a field with this name must exist)

Question

Recently I created a few ProtoFields in a Lua file that contains a dissector. The ProtoFields seem to work great when I test the dissector, and I can even use them as a display filter. The file looks like this:

proto_name = Proto("foo","FOO PROTOCOL")
msg_id = ProtoField.uint16 ("foo.msg_id", "msg_id", base.DEC, table_of_stuff)
msg_sub_id = ProtoField.uint16 ("foo.msg_sub_id", "msg_sub_id_unused")
msg_size = ProtoField.uint32 ("foo.msg_size", "msg_size")
proto_name.fields = {msg_id, msg_sub_id, msg_size}
function proto_name.dissector (buffer, pinfo, tree)
–fields are added to treeitems
end
tcp_table = DissectorTable.get("tcp.port")
tcp_table:add(<port number>, proto_name)

The problem occurs in a separate file, where I want to create a Listener to gather some statistics for the protocol. In this file I have

get_msg_id = Field.new("foo.msg_id")
–code below is never reached
–Listener function

I’m aware that Field objects have to be created outside of the callback functions of dissectors, post-dissectors, heuristic-dissectors, and taps, which is why I did so in my code.

My questions and concerns are:

Why are my fields in the Listener file not recognized, when they are clearly recognized in the dissector?

Are they instantly destroyed after they’re used in the dissector?

Do the Field extractors have to be created in the same file that the Protofields were created in?

Does the Listener have to be created in the same file as the Dissector for this particular scenario?

I really appreciate the help and advice!

Thanks,

Jeffrey

Answer 1

0

Well, first you have this:

get_msg_id = Field.new("proto_name.msg_id")

...but "proto_name" isn't the string name of your protocol - it's the name of a Lua variable that represents a Proto object. There is no protocol named "proto_name" in your example, but there is one named "foo". So the line should be:

get_msg_id = Field.new("foo.msg_id")

Also, you need to make sure the file that defines the new protocol (the one with the code at the beginning of your question) is loaded before the file with the Field.new() call.

answered 10 Jul '14, 09:06

Hadriel
2.7k●2●9●39
accept rate: 18%

I'm sorry I copied line of code incorrectly. I fixed the original post.

I have: get_msg_id = Field.new("foo.msg_id")

How is the load priority in \Wireshark\plugins\<version> decided for 2 lua source files?

I also placed both files in \Wireshark and tried at the bottom of the init.lua

dofile("dissector.lua")

dofile("listener.lua")

and received the same error. I figured Wireshark started with loading init.lua, and so before it did anything else I thought I could load them in here, where I can specify which loads before the other. Perhaps it's not doing what I think it's doing?

(10 Jul '14, 11:24) jphmiller

1

Sadly there is no specific order for files loaded from the plugin directory - the code relies on another library function to do it, which is known to not provide any specific ordering guarantee, and might be different on different operating systems or even disk formats.

Since your two files are not really independent, you could name the first one myproto.lua and the second one myproto.txt, so that wireshark only auto-loads the first one (it only auto-loads files with .lua extension), and then at the bottom of yourmyproto.luafile calldofile()` using the second file's name to load it. Or just combine the two files into one bigger file.

(10 Jul '14, 11:44) Hadriel

I tried both of those ideas and continued to receive:

bad argument #1 to 'new' (Field_new: a field with this name must exist)

Did I not register my protocol fields properly or something?

(10 Jul '14, 11:53) jphmiller

1

No you did register them, with this line:

proto_name.fields = {msg_id, msg_sub_id, msg_size}

... so long as the Field.new() is after that, it should work.

Oh... wait a minute... you're on 1.10.8 - try it on 1.12.0 instead. There was a bug that prevented a Lua-created ProtoField from being used by a Lua-based Field. It was fixed late last year, but my guess is not in 1.10.x.

(10 Jul '14, 14:38) Hadriel

Yep, that was it. I installed 1.12.0, plunked everything in and was good to go.

For anybody experiencing this same problem with the current stable version (1.10.8). The fix for this Field.new() bug (3513) was implemented in 1.11.2. You'll have to upgrade.

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3513

(11 Jul '14, 05:31) jphmiller