2006-05-30 19:45:12 +00:00
|
|
|
<!-- WSUG Appendix How it Works -->
|
2004-08-06 21:06:27 +00:00
|
|
|
<!-- $Id$ -->
|
|
|
|
|
|
|
|
<appendix id="AppHowItWorks">
|
2006-05-30 20:49:45 +00:00
|
|
|
<title>How Wireshark Works</title>
|
2004-08-06 21:06:27 +00:00
|
|
|
<para>
|
2006-05-30 20:49:45 +00:00
|
|
|
When using such a complex program like Wireshark, it's sometimes useful to
|
2004-08-06 21:06:27 +00:00
|
|
|
understand the mechanisms and concepts behind the surface. This is an
|
2006-05-30 20:49:45 +00:00
|
|
|
approach to shed some light on the inner workings of Wireshark.
|
2004-08-06 21:06:27 +00:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<section><title>Program start</title>
|
|
|
|
<para>
|
2006-08-27 11:46:02 +00:00
|
|
|
When Wireshark starts, a lot of things are done:
|
2004-08-06 21:06:27 +00:00
|
|
|
<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>
|
2007-09-10 21:02:58 +00:00
|
|
|
Each protocol has its own protocol dissector. A dissector is called from
|
2006-05-30 20:49:45 +00:00
|
|
|
Wireshark, if the packet data seems to be of that corresponding protocol. The
|
|
|
|
dissector will then process the packet data and call back Wireshark if it
|
2004-08-06 21:06:27 +00:00
|
|
|
couldn't dissect all the data in that packet to do any further dissections.
|
|
|
|
</para>
|
|
|
|
<para>
|
2006-05-30 20:49:45 +00:00
|
|
|
So Wireshark will dissect a packet from the lowest to the highest protocol
|
2004-08-06 21:06:27 +00:00
|
|
|
layers.
|
|
|
|
</para>
|
|
|
|
<para>
|
2006-05-30 20:49:45 +00:00
|
|
|
But how does Wireshark know, which dissector to choose?
|
2004-08-06 21:06:27 +00:00
|
|
|
</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
|
2006-05-30 20:49:45 +00:00
|
|
|
handover the packet to Wireshark's heuristic mechanism. This will ask all
|
2004-08-06 21:06:27 +00:00
|
|
|
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>
|
2006-05-30 20:49:45 +00:00
|
|
|
Let's look at an example: We'll assume, Wireshark loads a TCP/IP/Ethernet
|
|
|
|
packet. Wireshark will call the Ethernet dissector, which will dissect the
|
2004-08-06 21:06:27 +00:00
|
|
|
Ethernet related data (usually the first 6+6+2 bytes). Then this dissector
|
2006-05-30 20:49:45 +00:00
|
|
|
calls back into Wireshark and will pass the rest of the data back to
|
|
|
|
Wireshark. Wireshark in turn will call the next related dissector, in our case
|
2004-08-06 21:06:27 +00:00
|
|
|
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
|
2006-05-30 20:49:45 +00:00
|
|
|
is just unknown to Wireshark.
|
2004-08-06 21:06:27 +00:00
|
|
|
</para>
|
|
|
|
<para>
|
2007-09-10 21:02:58 +00:00
|
|
|
You can control the way Wireshark calls its dissectors, see <xref
|
2004-08-06 21:06:27 +00:00
|
|
|
linkend="ChAdvProtocolDissectionSection"/> for details.
|
|
|
|
</para>
|
|
|
|
</section>
|
|
|
|
|
|
|
|
</appendix>
|
2006-05-30 19:45:12 +00:00
|
|
|
<!-- End of WSUG Appendix How it Works -->
|