1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
<!-- WSUG Appendix How it Works -->
<!-- $Id$ -->
<appendix id="AppHowItWorks">
<title>How Ethereal Works</title>
<para>
When using such a complex program like Ethereal, it's sometimes useful to
understand the mechanisms and concepts behind the surface. This is an
approach to shed some light on the inner workings of Ethereal.
</para>
<section><title>Program start</title>
<para>
When Etheral starts, a lot of things are done:
<itemizedlist>
<listitem>
initialize the dissectors (register the protocol tree), including plugins
</listitem>
<listitem>
load and set values from the preferences file
</listitem>
<listitem>
load the capture filters from the cfilters file
</listitem>
<listitem>
load the display filters from the dfilters file
</listitem>
<listitem>
load and set the disabled protocols from the disabled_protos file
</listitem>
<listitem>
init libpcap/winpcap (the capturing engine)
</listitem>
<listitem>
process command line parameters
</listitem>
<listitem>
load and set the recently used GUI settings from the recent file
</listitem>
<listitem>
init and show the main screen
</listitem>
<listitem>
if specified by command line, load a capture file or start capturing
</listitem>
</itemizedlist>
</para>
<para>
</para>
</section>
<section><title>Protocol dissectors</title>
<para>
Each protocol has it's own protocol dissector. A dissector is called from
Ethereal, if the packet data seems to be of that corresponding protocol. The
dissector will then process the packet data and call back Ethereal if it
couldn't dissect all the data in that packet to do any further dissections.
</para>
<para>
So Ethereal will dissect a packet from the lowest to the highest protocol
layers.
</para>
<para>
But how does Ethereal know, which dissector to choose?
</para>
<para>
At program start, the dissector registers itself at the appropriate place(s).
There are two ways, how a dissector can register itself for packet data:
<itemizedlist>
<listitem>
<command>static</command> if the dissector knows a specific value
of a lower layer, if can directly register itself there (e.g. the HTTP
dissector "knows", that typically the well known TCP port 80 is used to
transport HTTP data).
</listitem>
<listitem>
<command>heuristic</command> if no such well known way exists, the dissector
can register itself for the heuristic mechanism. If a lower layer dissector
has to handle some packet data where no well known way exists, it can
handover the packet to Ethereal's heuristic mechanism. This will ask all
registered upper layer dissectors, if they "like" that data. Each of these
dissectors will typically look into the first few bytes of the packet, if it
contains some characteristic data of that protocol. So the dissector can
accept or reject to dissect that packet.
</listitem>
</itemizedlist>
</para>
<para>
Let's look at an example: We'll assume, Ethereal loads a TCP/IP/Ethernet
packet. Ethereal will call the Ethernet dissector, which will dissect the
Ethernet related data (usually the first 6+6+2 bytes). Then this dissector
calls back into Ethereal and will pass the rest of the data back to
Ethereal. Ethereal in turn will call the next related dissector, in our case
the IP dissector (because of the value 0x800 in the Ethernet type field).
This game will continue, until no more data has to be dissected, or the data
is just unknown to Ethereal.
</para>
<para>
You can control the way how Ethereal calls it's dissectors, see <xref
linkend="ChAdvProtocolDissectionSection"/> for details.
</para>
</section>
</appendix>
<!-- End of WSUG Appendix How it Works -->
|
