Chapter 9. Packet dissection

Table of Contents

9.1. How it works
9.2. Adding a basic dissector
9.2.1. Setting up the dissector
9.2.2. Dissecting the details of the protocol
9.2.3. Improving the dissection information
9.3. How to handle transformed data
9.4. How to reassemble split packets
9.4.1. How to reassemble split UDP packets
9.4.2. How to reassemble split TCP Packets
9.5. How to tap protocols
9.6. How to produce protocol stats
9.7. How to use conversations

9.1. How it works

Each dissector decodes its part of the protocol, and then hands off decoding to subsequent dissectors for an encapsulated protocol.

Every dissection starts with the Frame dissector which dissects the packet details of the capture file itself (e.g. timestamps). From there it passes the data on to the the lowest-level data dissector, e.g. the Ethernet dissector for the Ethernet header. The payload is then passed on to the next dissector (e.g. IP) and so on. At each stage, details of the packet will be decoded and displayed.

Dissection can be implemented in two possible ways. One is to have a dissector module compiled into the main program, which means it’s always available. Another way is to make a plugin (a shared library or DLL) that registers itself to handle dissection.

There is little difference in having your dissector as either a plugin or built-in. On the Windows platform you have limited function access through the ABI exposed in libwireshark.def, but that is mostly complete.

The big plus is that your rebuild cycle for a plugin is much shorter than for a built-in one. So starting with a plugin makes initial development simpler, while the finished code may make more sense as a built-in dissector.

[Note]Read README.developer

The file doc/README.developer contains detailed information about implementing a dissector. In many cases it is more up to date than this document.