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.
|
