> - continue what I have done so far, and use regular dissect routines
>> (requires some data to be preserved between dissect invocation). I made
>> assumption that dissect routines are invoked in order of packet arrival
>> (no sure).
>
>Yes, they're processed in order. During the initial pass,
>'tree' is set to NULL, so the proto dissection routines only parse enough
info
>to put into the list of packets. When a packet is selected via the GUI, or
>when a display filter is being processed, the proto dissection routine is
>called again, but this time with 'tree' pointing to something, telling
>the dissector that it needs the decode information.
The 'tree' value isn't set to NULL on the first pass if there is a color
filter
or a plugin filter. In that case the the 'tree' is always set to a non-NULL
value. A work around have found is to track the absoulte time values in the
frame_data parameter.
Here how I do it in a state based dissector...
/* variable definitions */
static guint32 last_abs_sec = 0;
static guint32 last_abs_uec;
/* the protocol re-init routine, registered with 'register_init_routine' */
void reinit_my_protocol {
last_abs_sec = 0;
/* the rest of the stuff */
}
/* the dissector code */
void dissect_my_protocol( const u_char *pd, int offset, frame_data *fd,
proto_tree *tree) {
if (( !last_abs_sec) ||
( last_abs_sec < fd->abs_sec ) ||
(( last_abs_sec == fd->abs_sec ) && ( last_abs_usec <
fd->abs_usec ))) {
last_abs_sec = fd->abs_sec;
last_abs_usec = fd->abs_usec;
/* we got a new packet, do the state based processing */
}
Jeff F.
jfoste@xxxxxxxxxxxx
