Wireshark-dev: Re: [Wireshark-dev] Dissectors and parsing mode
From: Guy Harris <[email protected]>
Date: Fri, 7 Nov 2008 17:08:40 -0800
On Nov 7, 2008, at 4:40 PM, Chris Davies wrote:

What seems to happen with my dissector is that when I load one of my
sample pcap files to test it out, my dissector is invoked for all the
relevant packets in order. However, at this stage although the
proto_tree* argument to the top level dissector function isn't null,
wireshark appears to ignore or deallocate any tree items I add at this
The protocol tree is not a persistent object.  A protocol tree will be  
removed, in its entirety, when Wireshark no longer needs it.   
("Wireshark" here refers to the Wireshark application core, not to any  
dissectors; dissectors shouldn't need the protocol tree, they should  
just construct it when asked to do so.)
(In the very early days of Wireshark development - it was still called  
Ethereal at that time - when the protocol tree was first introduced  
(prior to that the dissectors directly generated GTK+ trees), there  
was a bug at one point where the protocol tree was not getting freed  
(even though it was supposed to be freed).  This caused *huge* amounts  
of memory to be used when I tried reading in a large capture file, so  
protocol trees aren't going to be persistent objects - the memory  
requirements would be prohibitive for large captures.)
Then when I click on one of the DTN packets in the Wireshark
GUI, my dissector function is called again just for that one packet
Yes.  Your dissector can potentially be called multiple times for the  
same packet.
and this time the proto_tree* arg isn't null, and the tree items I add
show up. This is a bit of a problem for me, since really I want some
state information to know what sort of PDU I'm supposed to be parsing
from that particular packet.
Presumably by "state information" you mean "information from previous  
There are ways of keeping state information for purposes such as this;  
see my "advanced dissector writing" slides from SHARKFEST '08:

While I dare say I could examine the
first few bytes of the PDU and make a judgment about  what sort of PDU
it is, that isn't really how the protocol is supposed to work and
hence it isn't really how I'd like to parse it.
In the best of all possible worlds, where all the relevant packets are  
present in the capture, that shouldn't be how you have to parse it, if  
the packet type can be determined from previous packets in the session.
However, we don't live in the best of all possible worlds - a capture  
might start in the middle of a session - so, in addition to the state- 
management stuff I mention earlier, you might want to use heuristics  
if you don't have sufficient state information.