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
stage.
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
packets".
There are ways of keeping state information for purposes such as this;
see my "advanced dissector writing" slides from SHARKFEST '08:
http://www.cacetech.com/SHARKFEST.08/D03_Harris_Writing%20Wireshark%20Dissectors_Advanced.pdf
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.
