[Rayne <hjazz6@xxxxxxxxx>]

Replies below in blue.

I also have one other question: What happens when in the process of dissecting a packet, you encounter a protocol that is not recognized? What happens to that packet?

And thank you very much for your detailed reply!

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Mon, 9 Mar 2009 18:58:26 -0700

Also, are the dissectors in the heuristics list determined by statistics?

No.

For example, if say Protocol A follows Protocol B 80% of the time from traffic observed,

Which traffic?

At one site, protocol A might follow protocol B 80% of the time.  At  
another site, it might follow it 0% of the time, because, at that  
site, protocol A might not be used at all.

then Protocol A is included in the heuristic list of dissector to try by Protocol B?

If

	1) there's a dissector for protocol A;

	2) protocol A can follow (be encapsulated in) protocol B;

3) you can't tell by looking at some "next protocol" field in protocol B whether it's followed by protocol A or not, you have to guess by looking at the payload of protocol B;

4) protocol B supports heuristic dissectors for protocols that follow it;

5) whoever wrote the dissector for protocol B knew all that and knew that they should therefore make the dissector for protocol A a heuristic dissector for protocol B; then the proto_reg_handoff_ routine for the dissector module for protocol A would register the dissector for protocol A in the list of heuristic dissectors for protocol B.

Points 1 to 4 are the criteria for whether to include a protocol in the list of heuristic dissectors of another protocol?

And am I right to say that the protocol tree is built before the first packet is captured,

No, because there's no such thing as "*the* protocol tree" in general; a packet has *a* protocol tree that shows the dissection of all the protocols in that packet, so one can speak only of "the protocol tree" for a given packet, which obviously can't be created until that packet has been read. (Note that the packet might be captured minutes, or hours, or days, or weeks, or months, or years... before the packet is read; it might have been written to a capture file when it was captured, and Wireshark or TShark might be reading the file much later.)

I thought there was a general protocol tree that every packet would try to follow, like a roadmap, and it encompasses all possible known relationships among the various headers. For example, the IP header would branch out to other dissectors, such as TCP or UDP, and a packet would test for these other headers. Although I realize now this may be more of a conceptual idea than an implementation method.

So in reality, every packet has its own protocol tree that is built as protocols are dissected. So 2 packets may have very different protocol trees? Isn't this quite taxing for the system, because the system would have to keep track of all these protocol trees until the packets are completely dissected and the memory for the trees can be released? What is the purpose of building a protocol tree for every packet? Just to display that information for the user?

Where can I find an example where dissect-protocol() is called?

What do you mean by "dissect-protocol()"?

For example "dissect_ip()", "dissect_gtp()" etc.