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

Question

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?

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