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

Order of entries in dissector tables at startup and lua


Hello, I'm trying to modify RTP dissector table with Lua. When I create a Lua script like below and run it either from plugins directory or the command line it doesn't work, and I can see via Internals -> Dissector Tables that my entry was overwritten by AMR protocol.

local ip_dissector = Dissector.get("ip")
local rtp_table = DissectorTable.get("")
rtp_table:add(96, ip_dissector)

However, when I enter the same code via the evaluate window and reload the pcap file, it works as expected. This leads me to think that startup Lua code is executed before the other protocol adds itself to the same table, effectively being overwritten.

Am I right and, if yes, is there a way in which I can control that order? By maybe somehow putting that Lua code in a function and running it when all dissectors and protocols have been fully loaded?


asked 11 Jan '12, 09:07

izopizo's gravatar image

accept rate: 0%

edited 11 Jan '12, 10:06

multipleinterfaces's gravatar image


2 Answers:


AMR preferences

As @Anders pointed out, the problem is due to your preference for "AMR dynamic payload type" conflicting with your dissector registration. Set that preference to 0 to prevent AMR from being put into the dissector table for


Initialization order

Actually, the dissectors are not loaded randomly. Wireshark loads the C dissectors and then the Lua scripts, each of which is always loaded in the same order. Note that preferences are read last during initialization, which is the reason the AMR preference took effect over your Lua dissector.

The Makefile generates dissector-registration code (register.c) based on dissector source. The C dissectors are thus registered in the order seen in this generated code, which is ascending ASCII order.

Then, Lua scripts (which can contain dissectors) are also loaded in ascending ASCII order as follows:

  1. ${GLOBAL_CONFIG_DIR}/init.lua
  2. ${GLOBAL_PLUGINS_DIR}/**/*.lua
  3. ${PERSONAL_CONFIG_DIR}/init.lua
  4. ${PERSONAL_PLUGINS_DIR}/**/*.lua

The path variables above can be determined in Wireshark (Help > About > Folders). Example values:

Variable nameMac OSX valueWindows value

Control of initialization order

You can't change the initialization order of the C dissectors unless you modify the code. However, you do have control of Lua script loading, but it requires you to make changes to prevent the scripts from being auto-loaded:
  1. Move all Lua scripts outside of ${PERSONAL_PLUGINS_DIR} OR rename them to a different extension (such as ".lua_").
  2. Modify ${PERSONAL_CONFIG_DIR}/init.lua to explicitly load the Lua scripts in a specific order.

Example: Let's say I had this directory structure:

    |-- a.lua
    |-- b.lua
    -- x/
        |-- c.lua
        |-- d.lua
        |-- e.lua
        -- f.lua

...which has a load order of a through f. I want to change the order to "everything in the x directory alphabetically, then b, and a". So, I move the Lua scripts outside of ~/.wireshark/plugins to say, ~/.wireshark/lua/; and I add ~/.wireshark/init.lua, which contains:

-- USER_DIR is initialized in ${GLOBAL_CONFIG_DIR}/init.lua
local basedir = ( USER_DIR or persconffile_path() )..'lua/'

– load all Lua scripts in "~/.wireshark/lua/x" (ascending ASCII order) local xdir = basedir..'x/' for f in, ".lua") do dofile(xdir..f) end

dofile(basedir..'b.lua') dofile(basedir..'a.lua')

Assume the contents of each Lua script contains:

print( (require 'debug').getinfo(1).source )

which prints the absolute path to the running script. Now, if I start Wireshark or TShark, I should see the load order from the command line, like so:

$ tshark -v
TShark 1.7.1 (SVN Rev Unknown from unknown)

Copyright 1998-2012 Gerald Combs <[email protected]> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GLib 2.28.8, with libpcap (version unknown), with libz 1.2.5, without POSIX capabilities, with SMI 0.4.8, with c-ares 1.7.4, with Lua 5.1, with Python 2.7.1, with GnuTLS 2.8.6, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP.

Running on Mac OS 10.7.2 (Darwin 11.2.0), with locale en_US.UTF-8, with libpcap version 1.1.1, with libz 1.2.5.

Built using llvm-gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00).

answered 14 Jan ‘12, 10:42

helloworld's gravatar image

accept rate: 28%

edited 14 Jan ‘12, 10:42


Dissectors are loaded in a random order, and there is nothing you can do to control the specific order in which they are loaded. What you could do in stead is to disable the AMR protocol in Analyze -> Enabled Protocols (you may then need to restart Wireshark). This will prevent the AMR dissector from registering, which will prevent packets from being dissected as AMR packets (allowing you to use 96 for your own protocol). This shouldn't be a problem for you unless your dissector must perform a handoff to the AMR dissector.

The reason it works in the evaluate window is because all of the protocols are already registered at that point, so your dissector will be the last on to overwrite that table entry.

answered 11 Jan '12, 10:03

multipleinterfaces's gravatar image

accept rate: 12%

You can set the PT preference for AMR to 0

(11 Jan '12, 22:47) Anders ♦