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

What is the best way to track data between packets during dissection?


In brief: What is the best way to track information between protocol packets during dissection?

More detail: Suppose I have a protocol which has multiple message types, some of which can only be fully dissected if certain information from another message is known (example below). I could just have a static gint variable in my dissector that I update when data comes in, but this feels a little clunky. What is the best way to track this information so that dissection directed properly?

/* Message One "configuration" */
struct conf_mesg {
    guint8 configuration; /* 0==Type_foo, 1==Type_bar, etc. */

/* Message Two "data*/ struct data_mesg { guint32 data; /* guint16, guint16 if configuarion==Type_foo */ /* guint8, guint8, guint16 if configuration==Type_bar */ … };

At least one conf_mesg will come before a data_mesg in the protocol. The default behavior (where the conf_mesg was never seen or contained bogus data) should be to display the data field as a guint32. What is the best way to track what the configuration field of the last conf_mesg was during packet dissection?

asked 25 Aug ‘11, 07:07

multipleinterfaces's gravatar image

accept rate: 12%

One Answer:


I think using Wireshark "conversations" is probably the way to go.

From doc/README.developer:

"In wireshark a conversation is defined as a series of data packets between two address:port combinations"

A dissector can use a conversation to store state information about that conversation.

See section 2.1 of doc/README.developer for the details.

Keep in mind that Wireshark essentially does a first sequential dissection pass thru the capture file and then will re-dissect individual packets as the user selects particular packets.

So: If general information about the conversation ("config msg has been seen", etc) is not sufficient you may also need to store "per-packet" info to remember any decisions as to how to dissect a particular packet. See section 2.5 of doc/README.developer.

It's also probably worth spending a little time looking at some of the individual Wireshark dissectors to see how they use conversations.

answered 25 Aug '11, 07:33

Bill%20Meier's gravatar image

Bill Meier ♦♦
accept rate: 17%

edited 25 Aug '11, 08:03