This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Same Lua script works in Mac, Windows, but NOT Linux

0

Hi,

I've developed a Lua dissector that runs in the Mac and Windows version of Wireshark (binaries from recent nightly builds). Since there is no binary for Linux in the nightly builds, I built it from source for my ubuntu 12.04.

However, the behavior for the following lines of code has changed:

local packageID_string = string.format("0x%08x", packageID)
local funcName = "pkgExtract" .. packageID_string

if _G[funcName] ~= nil then _G[funcName](buffer, offset) else tree_payload:add(buffer(offset, pkg_payload_len), "Package ID not defined") end

Basically my payload has many differently structured packages. My script has many package specific functions. My code tell Wireshark to dynamically call the right function to dissect a particular package based on package ID.

The script works fine in Mac and Windows where it would call the right functions. But for some reason in Linux, instead of dissecting the packages, I get “Package ID not defined”. So it regards _G[funcName] to be nil. I printed the funcNames and they are correct and the functions are definitely defined in the script. What’s going on?

Here is my Wireshark flavor:

Version 1.11.3-2260-gf06cdf3 (Git Rev Unknown from unknown)

Compiled (64-bit) with GTK+ 3.4.2, with Cairo 1.10.2, with Pango 1.30.0, with GLib 2.32.4, with libpcap, with libz 1.2.3.4, without POSIX capabilities, without libnl, without SMI, without c-ares, without ADNS, with Lua 5.1, without Python, without GnuTLS, without Gcrypt, without Kerberos, without GeoIP, without PortAudio, with AirPcap. Running on Linux 3.2.0-29-generic, with locale en_US.UTF-8, with libpcap version 1.1.1, with libz 1.2.3.4, without AirPcap. Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz Built using gcc 4.6.3.

asked 07 Apr ‘14, 16:39

YXI's gravatar image

YXI
21182023
accept rate: 0%

edited 07 Apr ‘14, 19:03

Hadriel's gravatar image

Hadriel
2.7k2939

Can you show the code that sets the global _G[funcName] to be the function(s)?

(07 Apr ‘14, 19:07) Hadriel

BTW, not that it matters, but is there some reason you’re putting them in the global table instead of just a local table in the script? Are they set from other Lua scripts?

(07 Apr ‘14, 19:13) Hadriel

The functions are generated by python. I have python code writing to the Lua file lines like “function pkgExtract%s(buffer, offset)” %pkgID, which is the start of the function. Is this what you mean?

(07 Apr ‘14, 19:32) YXI

As far as global vs. local tables, I guess my Lua experience is so limited, I have not given it any thought. When you say local tables, do you mean declare all the functions as “local”?

(07 Apr ‘14, 19:36) YXI


One Answer:

1

It should behave the same in Linux, Mac, and Windows - there's been a recent change. What version were you running on Windows/Mac?


"When you say local tables, do you mean declare all the functions as "local"?"

When your script has this: "_G[funcName]", it's trying to access an entry in the Lua global table - an entry named whatever the variable funcName resolves to. ("_G" is the name of the global table)


"The functions are generated by python. I have python code writing to the Lua file lines like "function pkgExtract%s(buffer, offset)" %pkgID, which is the start of the function. Is this what you mean?"

You mean the Python code is writing something like this:

function pkgExtract0x0a01fe32(buffer, offset)
    -- do stuff
end

And it writes the above into the same Lua script file that has the code you posted in the question?

If so, then there's at least one problem: that doesn't actually create a global function named "pkgExtract0x0a01fe32" - i.e., it's not in the "_G" global table. Wireshark used to do that, but the code got changed recently to stop doing that. Instead, it creates a function of that name in the local file environment, meaning it's no longer global, and no longer put into the "_G" table. That was done to prevent Lua scripts from accidentally polluting the global table and affecting other scripts. (because people kept forgetting to use the word "local" before their variables and function definitions)

So change your Python code and the Lua code in your question to do this:

-- this is in your Lua file before the Python-generated code,
-- or Python generates one of these too (but only once)
local myfuncs = {}

– Python generates this function myfuncs.pkgExtract0x0a01fe32(buffer, offset) – do stuff end

– presumably this is in your dissector function local packageID_string = string.format("0x%08x", packageID) local funcName = "pkgExtract" .. packageID_string

if myfuncs[funcName] ~= nil then myfuncs[funcName](buffer, offset) else tree_payload:add(buffer(offset, pkg_payload_len), "Package ID not defined") end

BTW, there’s no need to do the string.format() and concatenation thing… Lua’s table keys can be numbers. So you could do this instead:

– this is in your Lua file before the Python-generated code,
– or Python generates one of these too (but only once)
local myfuncs = {}

– Python generates this - note the '0x0a01fe32' is not – in quotes, so it's a number key myfuncs[0x0a01fe32] = function(buffer, offset) – do stuff end

– presumably this is in your dissector function – the 'packageID' is a variable of a number, not a string if myfuncs[packageID] ~= nil then myfuncs[packageID](buffer, offset) else tree_payload:add(buffer(offset, pkg_payload_len), "Package ID not defined") end

answered 07 Apr ‘14, 20:37

Hadriel's gravatar image

Hadriel
2.7k2939
accept rate: 18%

edited 07 Apr ‘14, 20:38

You are right. Wireshark on my Mac and Windows are from the nightly builds about a month ago. When I downloaded the newest Mac version from last night, it behaves just like the Linux version. Thanks for helping me figure out how to cope with this.

Now this is one drawback of using nightly builds instead of a stable release. If I simply told other people to use the nightly build, my code would have been broken. Are you guys going to release what’s in the nightly builds (1.11.3) soon?

(08 Apr ‘14, 09:43) YXI

I’ve heard a rumor that the next stable release (1.12) is coming out in June - that will be whatever the 1.11.3 code is at that point in time; and then lucky release number 1.13 becomes the next development (unstable) release and 1.11.3 ends.

(08 Apr ‘14, 10:43) Hadriel

Apparently 1.11.3 is getting released on April 15th, and a 1.11.4 will be created for continued development; so whenever 1.12 gets released it will be based on 1.11.4 not 1.11.3 I think.

(08 Apr ‘14, 18:05) Hadriel

Would both GTK+ and QT versions be released together? I thought I read somewhere that GTK+ version is more stable.

(10 Apr ‘14, 09:11) YXI

You mean for 1.12, or 1.11.3?

For 1.11.3: linux and windows get both GTK and Qt, but Mac only gets Qt… or at least that’s all it’s gotten in the automated nightly builds, so I assume that’s all it will get in the released version of 1.11.3. Note that you can compile the Mac version on your own for both GTK and Qt.

It remains to be seen what happens with 1.12. The problem isn’t that Qt is less stable… the problem is it’s still missing a bunch of features that the GTK version has. For the features it has, Qt is superior in my opinion, but not having all the features is tough. Many of the missing features are really esoteric stuff that I bet only a very small, niche population uses… but some missing features aren’t so esoteric.

(10 Apr ‘14, 09:49) Hadriel