forked from osmocom/wireshark
![Gerald Combs](/assets/img/avatar_default.png)
to AsciiDoc. ``How Wireshark Works'' is disabled, so its final output hasn't been checked. Leave most of the content intact for now. Change-Id: Ia78951faa3ffd9c6d2e23067dbfb954ab4042f60 Reviewed-on: https://code.wireshark.org/review/5210 Reviewed-by: Gerald Combs <gerald@wireshark.org>
80 lines
3.1 KiB
Text
80 lines
3.1 KiB
Text
++++++++++++++++++++++++++++++++++++++
|
|
<!-- WSUG Appendix How it Works -->
|
|
++++++++++++++++++++++++++++++++++++++
|
|
|
|
[[AppHowItWorks]]
|
|
|
|
[appendix]
|
|
== How Wireshark Works
|
|
|
|
When using such a complex program like Wireshark, 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 Wireshark.
|
|
|
|
=== Program start
|
|
|
|
When Wireshark starts, a lot of things are done:
|
|
|
|
* Initialize the dissectors (register the protocol tree), including plugins
|
|
|
|
* Load and set values from the preferences file
|
|
|
|
* Load the capture filters from the cfilters file
|
|
|
|
* Load the display filters from the dfilters file
|
|
|
|
* Load and set the disabled protocols from the disabled_protos file
|
|
|
|
* Init libpcap/winpcap (the capturing engine)
|
|
|
|
* Process command line parameters
|
|
|
|
* Load and set the recently used GUI settings from the recent file
|
|
|
|
* Init and show the main screen
|
|
|
|
* If specified by command line, load a capture file or start capturing
|
|
|
|
=== Protocol dissectors
|
|
|
|
Each protocol has its own protocol dissector. A dissector is called from
|
|
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
|
|
couldn't dissect all the data in that packet to do any further dissections.
|
|
|
|
So Wireshark will dissect a packet from the lowest to the highest protocol
|
|
layers.
|
|
|
|
But how does Wireshark know, which dissector to choose?
|
|
|
|
At program start, the dissector registers itself at the appropriate place(s).
|
|
There are two ways for a dissector to register itself for packet data:
|
|
|
|
* _Static_. 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).
|
|
|
|
* _Heuristic_. 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 Wireshark'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.
|
|
|
|
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
|
|
Ethernet related data (usually the first 6+6+2 bytes). Then this dissector 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 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 Wireshark.
|
|
|
|
You can control the way Wireshark calls its dissectors, see
|
|
<<ChAdvProtocolDissectionSection>> for details.
|
|
|
|
++++++++++++++++++++++++++++++++++++++
|
|
<!-- End of WSUG Appendix How it Works -->
|
|
++++++++++++++++++++++++++++++++++++++ |