Building Wireshark from source and writing a custom dissector (including CORBA IDL)

Wireshark understands hundreds of protocols, but sooner or later you end up working with one it does not know: a proprietary protocol, an internal message format, CORBA traffic described by IDL files. Years ago I was in exactly that situation: to read the IDL messages of a system in clear text I had to build Wireshark from source and add a dissector generated from the IDL files. This page explains how it is done today, since the procedure has changed a lot, and when it is better not to recompile at all.

Before compiling: maybe Lua is enough

Wireshark runs dissectors written in Lua without recompiling anything. For a simple protocol it is the fastest route: write a .lua file, copy it into the personal plugins folder (shown in Help → About Wireshark → Folders) and restart the program.

-- myproto.lua: message with type (1 byte), length (2 bytes) and data
local p = Proto("myproto", "My protocol")
local f_type = ProtoField.uint8("myproto.type", "Type", base.DEC)
local f_len  = ProtoField.uint16("myproto.len", "Length", base.DEC)
local f_data = ProtoField.bytes("myproto.data", "Data")
p.fields = { f_type, f_len, f_data }

function p.dissector(buf, pinfo, tree)
    pinfo.cols.protocol = "MYPROTO"
    local t = tree:add(p, buf(), "My protocol")
    t:add(f_type, buf(0, 1))
    t:add(f_len, buf(1, 2))
    t:add(f_data, buf(3, buf(1, 2):uint()))
end

DissectorTable.get("tcp.port"):add(5000, p)

A C dissector is worth it when traffic is heavy and speed matters, when you want to hand colleagues a ready-made Wireshark build, or when the dissector is generated automatically, as with CORBA IDL files.

Building Wireshark on Linux

On Debian and Ubuntu it takes a handful of commands. The source code is on GitLab and includes a script that installs all the dependencies:

git clone https://gitlab.com/wireshark/wireshark.git
cd wireshark
sudo tools/debian-setup.sh --install-optional
mkdir build && cd build
cmake -G Ninja ..
ninja
./run/wireshark

The first build takes a few minutes; later builds only recompile what changed. For Fedora and derivatives there is the equivalent script tools/rpm-setup.sh.

Building Wireshark on Windows

Compared with the days of Visual C++ 2008, Cygwin and nmake, the path is much more straightforward now: CMake generates the Visual Studio solution and the third-party libraries are downloaded automatically. You need:

• Visual Studio 2022 (the free Community edition is fine) with the “Desktop development with C++” workload;
• Qt 6 for the user interface, installed with the Qt online installer (MSVC 64-bit component and the Qt5Compat module);
• Git, CMake, Python 3, Strawberry Perl and winflexbison, easy to install with Chocolatey: choco install -y git cmake python3 strawberryperl winflexbison3.

Then set the environment variable WIRESHARK_BASE_DIR (for example C:\Development, where the third-party libraries will go) and tell CMake where Qt is with CMAKE_PREFIX_PATH. From an “x64 Native Tools Command Prompt for VS 2022”:

cd C:\Development
git clone https://gitlab.com/wireshark/wireshark.git
mkdir wsbuild64 && cd wsbuild64
cmake -G "Visual Studio 17 2022" -A x64 ..\wireshark
msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln
run\RelWithDebInfo\Wireshark.exe

To create an installer for other people you also need NSIS and the wireshark_nsis_prep and wireshark_nsis projects, built with the same msbuild. The official Wireshark Developer’s Guide covers every detail and is worth checking whenever you change version, because the requirements are updated often.

A dissector generated from IDL files

Wireshark recognises CORBA’s GIOP/IIOP protocol, but without a description of the messages it only shows bytes. That description lives in the IDL files, and Wireshark ships a tool that turns them into a C dissector: idl2wrs, in the tools folder of the source tree. It relies on the omniORB IDL compiler (omniidl), which must be installed first.

idl2wrs messages.idl > packet-messages.c

The generated file becomes a plugin: put it in a folder under plugins/epan/ together with a CMakeLists.txt (you can copy one from an existing plugin, such as plugins/epan/gryphon, and change the names), then add the folder to the list of custom plugins by copying CMakeListsCustom.txt.example to CMakeListsCustom.txt. A new build produces the plugin’s DLL or shared library.

Some advice from experience:

• If there are many IDL files, collect them in a single folder keeping the subfolder structure and generate the C files with a script, so repeating the job for every IDL revision takes minutes.
• The generated code does not always compile cleanly with recent compilers: unused variables and duplicate declarations are the most common errors. The compiler messages point exactly to what needs fixing.
• Telling your build apart from the official one helps a lot: add a recognisable suffix to the project version (in the top-level CMakeLists.txt) and the About window shows straight away which build you are using and with which IDL revision.

A note on timestamps on Windows

In the WinPcap days, on some multiprocessor virtual machines packet timestamps could come out non-monotonic, and the fix was to change the driver’s timing mode in the registry, giving up microsecond precision. Today Wireshark uses Npcap, which lets you choose the timestamp type directly from the capture options. If you measure response times down to the millisecond, still check clock synchronisation and capture on a physical machine when you can.

If you need help building Wireshark or writing a dissector, leave a comment below.