Wireshark-dev: Re: [Wireshark-dev] What is the best way to create a stateful dissector?
On 11/22/2011 6:38 PM, Bill Meier wrote:
On 11/22/2011 6:19 PM, Kenny Ho wrote:
Hi,
I am writing my first dissector and it needs to dissect a packet base
on some information in previous packets. The protocol also allows
multiple of these stream mux together. What is the best way to
create a stateful dissector? From the dev guide, I notice there are
two different mechanisms that is "stateful" - the tap and the
"conversation". From what I can tell, tap seems to be for
post-processing of stats only. So is the "conversation" mechanism
the best way to implement a stateful dissector?
Yes: In addition to the dev guide, see doc/README.developer.
Did I miss any some other mechanism?
Note that it's possible (but less desirable due to memory usage) to store
"per-packet" state info (see README.developer section 2.5).
Be aware that after the first pass that packets may be redissected in
any order depending upon factors such as when they are selected or when
they are displayed and so on.
'pinfo->fd->flags.visited' can be examined to determine if a frame is
being dissected for the first time (during the first pass when a file is
being read).
(See below for some recent comments by Guy Harris).
So, it may be the case that you'll need to store "per-frame" info about
any decisions made as to how to dissect a particular packet based upon a
previous packet.
When an arbitrary packet is then dissected again later the associated
per-packet info is used to do the dissection in the same way as done
during the first sequential pass.
====================
Comments bu Guy Harris from a recent -dev EMail
For "pass" in the sense of "sequential pass over all packets", there is
no guarantee that there's more than one "pass", that pass being the one
where the file is read in. However, packets can, after they've been
dissected in the first pass, be subsequently visited in any order (no
guarantee that it's sequential).
There is also no guarantee that tree will, or will not, be null on the
first pass; dissectors should make no assumptions about that.
All work to construct state needed for request/response tracking, etc.
must be done in the first pass, regardless of whether tree is null or
not (see the note two paragraphs ago about visits to packets after
they've been dissected in the first pass, in particular "no guarantee
that it's sequential").
