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.8. idl2wrs: Creating dissectors from CORBA IDL files
9.8.1. What is it?
9.8.2. Why do this?
9.8.3. How to use idl2wrs
9.8.4. TODO
9.8.5. Limitations
9.8.6. Notes

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 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 by functions declared as WS_DLL_PUBLIC.

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.dissector

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