Wireshark-dev: Re: [Wireshark-dev] Dissectors and parsing mode
From: Guy Harris <guy@xxxxxxxxxxxx>
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 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.
- References:
- [Wireshark-dev] Dissectors and parsing mode
- From: Chris Davies
- [Wireshark-dev] Dissectors and parsing mode
- Prev by Date: Re: [Wireshark-dev] Dissectors and parsing mode
- Next by Date: Re: [Wireshark-dev] custom plugin dll - can it be dropped intoanother WS installation?
- Previous by thread: Re: [Wireshark-dev] Dissectors and parsing mode
- Next by thread: [Wireshark-dev] Wireshark as a hex viewer?
- Index(es):
- Get Wireshark
- Download
- Code of Conduct