Chapter 9. Packet Dissection

Table of Contents

9.1. How packet dissection works
9.2. Adding a basic dissector
9.2.1. Setting up the dissector
9.2.2. Dissecting the protocol’s details
9.2.3. Improving the dissection information
9.3. How to add an expert item
9.4. How to handle transformed data
9.5. How to reassemble split packets
9.5.1. How to reassemble split UDP packets
9.5.2. How to reassemble split TCP Packets
9.6. How to tap protocols
9.7. How to produce protocol stats
9.8. How to use conversations
9.9. idl2wrs: Creating dissectors from CORBA IDL files
9.9.1. What is it?
9.9.2. Why do this?
9.9.3. How to use idl2wrs
9.9.4. TODO
9.9.5. Limitations
9.9.6. Notes

9.1. How packet dissection 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 details of the capture file itself (e.g. timestamps). From there it passes the data on to 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 are decoded and displayed.

Dissectors can either be built-in to Wireshark or written as a self-registering plugin (a shared library or DLL). There is little difference in having your dissector as either a plugin or built-in. You have limited function access through the ABI exposed by functions declared as WS_DLL_PUBLIC.

The big benefit of writing a dissector as a plugin is that rebuilding a plugin is much faster than rebuilding wireshark after editing a built-in dissector. As such, starting with a plugin often makes initial development quicker, while the finished code may make more sense as a built-in dissector.

[Note]Read README.dissector

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