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.
_______________________________________________
Wireshark-dev mailing list
[email protected]
https://wireshark.org/mailman/listinfo/wireshark-dev
