1015 lines
47 KiB
XML
1015 lines
47 KiB
XML
<!-- WSUG Chapter Advanced -->
|
|
<!-- $Id$ -->
|
|
<chapter id="ChapterAdvanced">
|
|
<title>Advanced Topics</title>
|
|
<section id="ChAdvIntroduction">
|
|
<title>Introduction</title>
|
|
<para>In this chapter some of the advanced features of
|
|
Wireshark will be described.</para>
|
|
</section>
|
|
<section id="ChAdvFollowTCPSection">
|
|
<title>Following TCP streams</title>
|
|
<para>If you are working with TCP based protocols it can be
|
|
very helpful to see the data from a TCP stream in the way that
|
|
the application layer sees it. Perhaps you are looking for
|
|
passwords in a Telnet stream, or you are trying to make sense
|
|
of a data stream. Maybe you just need a display filter to show
|
|
only the packets of that TCP stream. If so, Wireshark's ability
|
|
to follow a TCP stream will be useful to you.</para>
|
|
<para>Simply select a TCP packet in the packet list of the
|
|
stream/connection you are interested in and then select the
|
|
Follow TCP Stream menu item from the Wireshark Tools menu (or
|
|
use the context menu in the packet list). Wireshark will set an
|
|
appropriate display filter and pop up a dialog box with all the
|
|
data from the TCP stream laid out in order, as shown in
|
|
<xref linkend="ChAdvFollowStream" />.</para>
|
|
<note>
|
|
<title>Note!</title>
|
|
<para>It is worthwhile noting that Follow TCP Stream installs
|
|
a display filter to select all the packets in the TCP stream
|
|
you have selected.</para>
|
|
</note>
|
|
<section>
|
|
<title>The "Follow TCP Stream" dialog box</title>
|
|
<figure id="ChAdvFollowStream">
|
|
<title>The "Follow TCP Stream" dialog box</title>
|
|
<graphic entityref="WiresharkFollowStream" format="PNG" />
|
|
</figure>
|
|
<para>The stream content is displayed in the same sequence as
|
|
it appeared on the network. Traffic from A to B is marked in
|
|
red, while traffic from B to A is marked in blue. If you
|
|
like, you can change these colors in the Edit/Preferences
|
|
"Colors" page.</para>
|
|
<para>Non-printable characters will be replaced by dots. XXX
|
|
- What about line wrapping (maximum line length) and CRNL
|
|
conversions?</para>
|
|
<para>The stream content won't be updated while doing a live
|
|
capture. To get the latest content you'll have to reopen the
|
|
dialog.</para>
|
|
<para>You can choose from the following actions:
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>
|
|
<command>Save As</command>: Save the stream data in the
|
|
currently selected format.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Print</command>: Print the stream data in the
|
|
currently selected format.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Direction</command>: Choose the stream direction
|
|
to be displayed ("Entire conversation", "data from A to B
|
|
only" or "data from B to A only").</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Filter out this stream</command>: Apply a display
|
|
filter removing the current TCP stream data from the
|
|
display.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Close</command>: Close this dialog box, leaving
|
|
the current display filter in effect.</para>
|
|
</listitem>
|
|
</orderedlist></para>
|
|
<para>You can choose to view the data in one of the following
|
|
formats:
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>
|
|
<command>ASCII</command>: In this view you see the data
|
|
from each direction in ASCII. Obviously best for ASCII
|
|
based protocols, e.g. HTTP.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>EBCDIC</command>: For the big-iron freaks out
|
|
there.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>HEX Dump</command>: This allows you to see all
|
|
the data. This will require a lot of screen space and is
|
|
best used with binary protocols.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>C Arrays</command>: This allows you to import
|
|
the stream data into your own C program.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Raw</command>: This allows you to load the
|
|
unaltered stream data into a different program for
|
|
further examination. The display will look the same as
|
|
the ASCII setting, but "Save As" will result in a binary
|
|
file.</para>
|
|
</listitem>
|
|
</orderedlist></para>
|
|
</section>
|
|
</section>
|
|
<section id="ChAdvExpert">
|
|
<title>Expert Infos</title>
|
|
<para>The expert infos is a kind of log of the anomalies found
|
|
by Wireshark in a capture file.</para>
|
|
<para>The general idea behind the following "Expert Info" is to
|
|
have a better display of "uncommon" or just notable network
|
|
behaviour. This way, both novice and expert users will
|
|
hopefully find probable network problems a lot faster, compared
|
|
to scanning the packet list "manually" .</para>
|
|
<warning>
|
|
<title>Expert infos are only a hint!</title>
|
|
<para>Take expert infos as a hint what's worth looking at,
|
|
but not more. For example: The absence of expert infos
|
|
doesn't necessarily mean everything is ok!</para>
|
|
</warning>
|
|
<note>
|
|
<title>The amount of expert infos largely depends on the
|
|
protocol being used!</title>
|
|
<para>While some common protocols like TCP/IP will show
|
|
detailed expert infos, most other protocols currently won't
|
|
show any expert infos at all.</para>
|
|
</note>
|
|
<para>The following will first describe the components of a
|
|
single expert info, then the User Interface.</para>
|
|
<section id="ChAdvExpertInfoEntries">
|
|
<title>Expert Info Entries</title>
|
|
<para>Each expert info will contain the following things
|
|
which will be described in detail below:
|
|
<table id="ChAdvTabExpertInfoEntries" frame="none">
|
|
<title>Some example expert infos</title>
|
|
<tgroup cols="7">
|
|
<thead>
|
|
<row>
|
|
<entry>Packet #</entry>
|
|
<entry>Severity</entry>
|
|
<entry>Group</entry>
|
|
<entry>Protocol</entry>
|
|
<entry>Summary</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry>1</entry>
|
|
<entry>Note</entry>
|
|
<entry>Sequence</entry>
|
|
<entry>TCP</entry>
|
|
<entry>Duplicate ACK (#1)</entry>
|
|
</row>
|
|
<row>
|
|
<entry>2</entry>
|
|
<entry>Chat</entry>
|
|
<entry>Sequence</entry>
|
|
<entry>TCP</entry>
|
|
<entry>Connection reset (RST)</entry>
|
|
</row>
|
|
<row>
|
|
<entry>8</entry>
|
|
<entry>Note</entry>
|
|
<entry>Sequence</entry>
|
|
<entry>TCP</entry>
|
|
<entry>Keep-Alive</entry>
|
|
</row>
|
|
<row>
|
|
<entry>9</entry>
|
|
<entry>Warn</entry>
|
|
<entry>Sequence</entry>
|
|
<entry>TCP</entry>
|
|
<entry>Fast retransmission (suspected)</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table></para>
|
|
<section id="ChAdvExpertSeverity">
|
|
<title>Severity</title>
|
|
<para>Every expert info has a specific severity level. The
|
|
following severity levels are used, in parentheses are the
|
|
colors in which the items will be marked in the GUI:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<command>Chat (grey)</command>: information about usual
|
|
workflow, e.g. a TCP packet with the SYN flag
|
|
set</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Note (cyan)</command>: notable things, e.g. an
|
|
application returned an "usual" error code like HTTP
|
|
404</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Warn (yellow)</command>: warning, e.g.
|
|
application returned an "unusual" error code like a
|
|
connection problem</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Error (red)</command>: serious problem, e.g.
|
|
[Malformed Packet]</para>
|
|
</listitem>
|
|
</itemizedlist></para>
|
|
</section>
|
|
<section id="ChAdvExpertGroup">
|
|
<title>Group</title>
|
|
<para>There are some common groups of expert infos. The
|
|
following are currently implemented:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<command>Checksum</command>: a checksum was
|
|
invalid</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Sequence</command>: protocol sequence
|
|
suspicious, e.g. sequence wasn't continuous or a
|
|
retransmission was detected or ...</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Response Code</command>: problem with
|
|
application response code, e.g. HTTP 404 page not
|
|
found</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Request Code</command>: an application request
|
|
(e.g. File Handle == x), usually Chat level</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Undecoded</command>: dissector incomplete or
|
|
data can't be decoded for other reasons</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Reassemble</command>: problems while
|
|
reassembling, e.g. not all fragments were available or
|
|
an exception happened while reassembling</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Protocol</command>: violation of protocol specs
|
|
(e.g. invalid field values or illegal lengths),
|
|
dissection of this packet is probably continued</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Malformed</command>: malformed packet or
|
|
dissector has a bug, dissection of this packet
|
|
aborted</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Debug</command>: debugging (should not occur in
|
|
release versions)</para>
|
|
</listitem>
|
|
</itemizedlist>It's possible that more such group values
|
|
will be added in the future ...</para>
|
|
</section>
|
|
<section id="ChAdvExpertProtocol">
|
|
<title>Protocol</title>
|
|
<para>The protocol in which the expert info was
|
|
caused.</para>
|
|
</section>
|
|
<section id="ChAdvExpertSummary">
|
|
<title>Summary</title>
|
|
<para>Each expert info will also have a short additional
|
|
text with some further explanation.</para>
|
|
</section>
|
|
</section>
|
|
<section id="ChAdvExpertDialog">
|
|
<title>"Expert Info" dialog</title>
|
|
<para>From the main menu you can open the expert info dialog,
|
|
using: "Analyze/Expert Info"</para>
|
|
<para>XXX - add explanation of the dialogs context
|
|
menu.</para>
|
|
<graphic entityref="WiresharkExpertInfoDialog"
|
|
format="PNG" />
|
|
<section id="ChAdvExpertDialogTabs">
|
|
<title>Errors / Warnings / Notes / Chats tabs</title>
|
|
<para>An easy and quick way to find the most interesting
|
|
infos (rather than using the Details tab), is to have a look at the
|
|
separate tabs for each severity level. As the tab label
|
|
also contains the number of existing entries, it's easy to
|
|
find the tab with the most important entries.</para>
|
|
<para>There are usually a lot of identical expert infos
|
|
only differing in the packet number. These identical infos
|
|
will be combined into a single line - with a count column
|
|
showing how often they appeared in the capture file. Clicking on
|
|
the plus sign shows the individual packet numbers in a tree
|
|
view.</para>
|
|
</section>
|
|
<section id="ChAdvExpertDialogDetails">
|
|
<title>Details tab</title>
|
|
<para>The Details tab provides the expert infos in a "log
|
|
like" view, each entry on its own line (much like the
|
|
packet list). As the amount of expert infos for a capture
|
|
file can easily become very large, getting an idea of the
|
|
interesting infos with this view can take quite a while.
|
|
The advantage of this tab is to have all entries in the
|
|
sequence as they appeared, this is sometimes a help to
|
|
pinpoint problems.</para>
|
|
</section>
|
|
</section>
|
|
<section id="ChAdvExpertColorizedTree">
|
|
<title>"Colorized" Protocol Details Tree</title>
|
|
<graphic entityref="WiresharkExpertColoredTree"
|
|
format="PNG" />
|
|
<para>The protocol field causing an expert info is colorized,
|
|
e.g. uses a cyan background for a note severity level. This
|
|
color is propagated to the toplevel protocol item in the
|
|
tree, so it's easy to find the field that caused the expert
|
|
info.</para>
|
|
<para>For the example screenshot above, the IP "Time to live"
|
|
value is very low (only 1), so the corresponding protocol
|
|
field is marked with a cyan background. To easier find that
|
|
item in the packet tree, the IP protocol toplevel item is
|
|
marked cyan as well.</para>
|
|
</section>
|
|
<section id="ChAdvExpertColumn">
|
|
<title>"Expert" Packet List Column (optional)</title>
|
|
<graphic entityref="WiresharkExpertColumn" format="PNG" />
|
|
<para>An optional "Expert Info Severity" packet list column
|
|
is available (since SVN 22387 → 0.99.7), that displays
|
|
the most significant severity of a packet, or stays empty if
|
|
everything seems ok. This column is not displayed by default,
|
|
but can be easily added using the Preferences Columns page
|
|
described in
|
|
<xref linkend="ChCustPreferencesSection" />.</para>
|
|
</section>
|
|
</section>
|
|
<section id="ChAdvTimestamps">
|
|
<title>Time Stamps</title>
|
|
<para>Time stamps, their precisions and all that can be quite
|
|
confusing. This section will provide you with information about
|
|
what's going on while Wireshark processes time stamps.</para>
|
|
<para>While packets are captured, each packet is time stamped
|
|
as it comes in. These time stamps will be saved to the capture
|
|
file, so they also will be available for (later)
|
|
analysis.</para>
|
|
<para>So where do these time stamps come from? While capturing,
|
|
Wireshark gets the time stamps from the libpcap (WinPcap)
|
|
library, which in turn gets them from the operating system
|
|
kernel. If the capture data is loaded from a capture file,
|
|
Wireshark obviously gets the data from that file.</para>
|
|
<section>
|
|
<title>Wireshark internals</title>
|
|
<para>The internal format that Wireshark uses to keep a
|
|
packet time stamp consists of the date (in days since
|
|
1.1.1970) and the time of day (in nanoseconds since
|
|
midnight). You can adjust the way Wireshark displays the time
|
|
stamp data in the packet list, see the "Time Display Format"
|
|
item in the
|
|
<xref linkend="ChUseViewMenuSection" /> for details.</para>
|
|
<para>While reading or writing capture files, Wireshark
|
|
converts the time stamp data between the capture file format
|
|
and the internal format as required.</para>
|
|
<para>While capturing, Wireshark uses the libpcap (WinPcap)
|
|
capture library which supports microsecond resolution. Unless
|
|
you are working with specialized capturing hardware, this
|
|
resolution should be adequate.</para>
|
|
</section>
|
|
<section>
|
|
<title>Capture file formats</title>
|
|
<para>Every capture file format that Wireshark knows supports
|
|
time stamps. The time stamp precision supported by a specific
|
|
capture file format differs widely and varies from one second
|
|
"0" to one nanosecond "0.123456789". Most file formats store
|
|
the time stamps with a fixed precision (e.g. microseconds),
|
|
while some file formats are even capable of storing the time
|
|
stamp precision itself (whatever the benefit may be).</para>
|
|
<para>The common libpcap capture file format that is used by
|
|
Wireshark (and a lot of other tools) supports a fixed
|
|
microsecond resolution "0.123456" only.</para>
|
|
<note>
|
|
<title>Note!</title>
|
|
<para>Writing data into a capture file format that doesn't
|
|
provide the capability to store the actual precision will
|
|
lead to loss of information. Example: If you load a capture
|
|
file with nanosecond resolution and store the capture data
|
|
to a libpcap file (with microsecond resolution) Wireshark
|
|
obviously must reduce the precision from nanosecond to
|
|
microsecond.</para>
|
|
</note>
|
|
</section>
|
|
<section>
|
|
<title>Accuracy</title>
|
|
<para>It's often asked: "Which time stamp accuracy is
|
|
provided by Wireshark?". Well, Wireshark doesn't create any
|
|
time stamps itself but simply gets them from "somewhere else"
|
|
and displays them. So accuracy will depend on the capture
|
|
system (operating system, performance, ...) that you use.
|
|
Because of this, the above question is difficult to answer in
|
|
a general way.
|
|
<note>
|
|
<title>Note!</title>
|
|
<para>USB connected network adapters often provide a very
|
|
bad time stamp accuracy. The incoming packets have to take
|
|
"a long and winding road" to travel through the USB cable
|
|
until they actually reach the kernel. As the incoming
|
|
packets are time stamped when they are processed by the
|
|
kernel, this time stamping mechanism becomes very
|
|
inaccurate.</para>
|
|
<para>Conclusion: don't use USB connected NIC's when you
|
|
need precise time stamp accuracy! (XXX - are there any such
|
|
NIC's that generate time stamps on the USB hardware?)</para>
|
|
</note></para>
|
|
</section>
|
|
</section>
|
|
<section id="ChAdvTimezones">
|
|
<title>Time Zones</title>
|
|
<para>If you travel across the planet, time zones can be
|
|
confusing. If you get a capture file from somewhere around the
|
|
world time zones can even be a lot more confusing ;-)</para>
|
|
<para>First of all, there are two reasons why you may not need
|
|
to think about time zones at all:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>You are only interested in the time differences
|
|
between the packet time stamps and don't need to know the
|
|
exact date and time of the captured packets (which is often
|
|
the case).</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>You don't get capture files from different time zones
|
|
than your own, so there are simply no time zone problems.
|
|
For example: everyone in your team is working in the same
|
|
time zone as yourself.</para>
|
|
</listitem>
|
|
</itemizedlist></para>
|
|
<sidebar>
|
|
<title>What are time zones?</title>
|
|
<para>People expect that the time reflects the sunset. Dawn
|
|
should be in the morning maybe around 06:00 and dusk in the
|
|
evening maybe at 20:00. These times will obviously vary
|
|
depending on the season. It would be very confusing if
|
|
everyone on earth would use the same global time as this
|
|
would correspond to the sunset only at a small part of the
|
|
world.</para>
|
|
<para>For that reason, the earth is split into several
|
|
different time zones, each zone with a local time that
|
|
corresponds to the local sunset.</para>
|
|
<para>The time zone's base time is UTC (Coordinated Universal
|
|
Time) or Zulu Time (military and aviation). The older term
|
|
GMT (Greenwich Mean Time) shouldn't be used as it is slightly
|
|
incorrect (up to 0.9 seconds difference to UTC). The UTC base
|
|
time equals to 0 (based at Greenwich, England) and all time
|
|
zones have an offset to UTC between -12 to +14 hours!</para>
|
|
<para>For example: If you live in Berlin you are in a time
|
|
zone one hour earlier than UTC, so you are in time zone "+1"
|
|
(time difference in hours compared to UTC). If it's 3 o'clock
|
|
in Berlin it's 2 o'clock in UTC "at the same moment".</para>
|
|
<para>Be aware that at a few places on earth don't use time
|
|
zones with even hour offsets (e.g. New Delhi uses
|
|
UTC+05:30)!</para>
|
|
<para>Further information can be found at:
|
|
<ulink url="&WikipediaTimezone;">
|
|
&WikipediaTimezone;</ulink> and
|
|
<ulink url="&WikipediaUTC;">
|
|
&WikipediaUTC;</ulink>.</para>
|
|
</sidebar>
|
|
<sidebar>
|
|
<title>What is daylight saving time (DST)?</title>
|
|
<para>Daylight Saving Time (DST), also known as Summer Time,
|
|
is intended to "save" some daylight during the summer months.
|
|
To do this, a lot of countries (but not all!) add a DST hour
|
|
to the already existing UTC offset. So you may need to take
|
|
another hour (or in very rare cases even two hours!)
|
|
difference into your "time zone calculations".</para>
|
|
<para>Unfortunately, the date at which DST actually takes
|
|
effect is different throughout the world. You may also note,
|
|
that the northern and southern hemispheres have opposite
|
|
DST's (e.g. while it's summer in Europe it's winter in
|
|
Australia).</para>
|
|
<para>Keep in mind: UTC remains the same all year around,
|
|
regardless of DST!</para>
|
|
<para>Further information can be found at:
|
|
<ulink url="&WikipediaDaylightSaving;">
|
|
&WikipediaDaylightSaving;</ulink>.</para>
|
|
</sidebar>
|
|
<para>Further time zone and DST information can be found at:
|
|
<ulink url="&TimezoneGMTSite;">
|
|
&TimezoneGMTSite;</ulink> and
|
|
<ulink url="&TimezoneWorldClockSite;">
|
|
&TimezoneWorldClockSite;</ulink>.</para>
|
|
<section>
|
|
<title>Set your computer's time correctly!</title>
|
|
<para>If you work with people around the world, it's very
|
|
helpful to set your computer's time and time zone
|
|
right.</para>
|
|
<para>You should set your computers time and time zone in the
|
|
correct sequence:
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Set your time zone to your current location</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Set your computer's clock to the local time</para>
|
|
</listitem>
|
|
</orderedlist>This way you will tell your computer both the
|
|
local time and also the time offset to UTC.
|
|
<tip>
|
|
<title>Tip!</title>
|
|
<para>If you travel around the world, it's an often made
|
|
mistake to adjust the hours of your computer clock to the
|
|
local time. Don't adjust the hours but your time zone
|
|
setting instead! For your computer, the time is essentially
|
|
the same as before, you are simply in a different time zone
|
|
with a different local time!</para>
|
|
</tip>
|
|
<tip>
|
|
<title>Tip!</title>
|
|
<para>You can use the Network Time Protocol (NTP) to
|
|
automatically adjust your computer to the correct time, by
|
|
synchronizing it to Internet NTP clock servers. NTP clients
|
|
are available for all operating systems that Wireshark
|
|
supports (and for a lot more), for examples see:
|
|
<ulink url="&NTPSite;">&NTPSite;</ulink>.</para>
|
|
</tip></para>
|
|
</section>
|
|
<section>
|
|
<title>Wireshark and Time Zones</title>
|
|
<para>So what's the relationship between Wireshark and time
|
|
zones anyway?</para>
|
|
<para>Wireshark's native capture file format (libpcap
|
|
format), and some other capture file formats, such as the
|
|
Windows Sniffer, EtherPeek, AiroPeek, and Sun snoop formats,
|
|
save the arrival time of packets as UTC values. UN*X systems,
|
|
and "Windows NT based" systems (Windows NT 4.0, 2000, XP,
|
|
Server 2003, Vista, Server 2008, 7) represent
|
|
time internally as UTC. When Wireshark is capturing, no
|
|
conversion is necessary. However, if the system time zone is
|
|
not set correctly, the system's UTC time might not be
|
|
correctly set even if the system clock appears to display
|
|
correct local time. "Windows 9x based" systems (Windows 95,
|
|
Windows 98, Windows Me) represent time internally as local
|
|
time. When capturing, WinPcap has to convert the time to UTC
|
|
before supplying it to Wireshark. If the system's time zone
|
|
is not set correctly, that conversion will not be done
|
|
correctly.</para>
|
|
<para>Other capture file formats, such as the Microsoft
|
|
Network Monitor, DOS-based Sniffer, and Network Instruments
|
|
Observer formats, save the arrival time of packets as local
|
|
time values.</para>
|
|
<para>Internally to Wireshark, time stamps are represented in
|
|
UTC; this means that, when reading capture files that save
|
|
the arrival time of packets as local time values, Wireshark
|
|
must convert those local time values to UTC values.</para>
|
|
<para>Wireshark in turn will display the time stamps always
|
|
in local time. The displaying computer will convert them from
|
|
UTC to local time and displays this (local) time. For capture
|
|
files saving the arrival time of packets as UTC values, this
|
|
means that the arrival time will be displayed as the local
|
|
time in your time zone, which might not be the same as the
|
|
arrival time in the time zone in which the packet was
|
|
captured. For capture files saving the arrival time of
|
|
packets as local time values, the conversion to UTC will be
|
|
done using your time zone's offset from UTC and DST rules,
|
|
which means the conversion will not be done correctly; the
|
|
conversion back to local time for display might undo this
|
|
correctly, in which case the arrival time will be displayed
|
|
as the arrival time in which the packet was captured.</para>
|
|
<para>
|
|
<table id="ChAdvTabTimezones" frame="none">
|
|
<title>Time zone examples for UTC arrival times (without
|
|
DST)</title>
|
|
<tgroup cols="7">
|
|
<!-- <colspec colnum="1" colwidth="72pt"/>
|
|
<colspec colnum="2" colwidth="80pt"/>
|
|
<colspec colnum="3" colwidth="80pt"/>-->
|
|
<thead>
|
|
<row>
|
|
<entry></entry>
|
|
<entry>Los Angeles</entry>
|
|
<entry>New York</entry>
|
|
<entry>Madrid</entry>
|
|
<entry>London</entry>
|
|
<entry>Berlin</entry>
|
|
<entry>Tokyo</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry>
|
|
<command>Capture File (UTC)</command>
|
|
</entry>
|
|
<entry>10:00</entry>
|
|
<entry>10:00</entry>
|
|
<entry>10:00</entry>
|
|
<entry>10:00</entry>
|
|
<entry>10:00</entry>
|
|
<entry>10:00</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<command>Local Offset to UTC</command>
|
|
</entry>
|
|
<entry>-8</entry>
|
|
<entry>-5</entry>
|
|
<entry>-1</entry>
|
|
<entry>0</entry>
|
|
<entry>+1</entry>
|
|
<entry>+9</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<command>Displayed Time (Local Time)</command>
|
|
</entry>
|
|
<entry>02:00</entry>
|
|
<entry>05:00</entry>
|
|
<entry>09:00</entry>
|
|
<entry>10:00</entry>
|
|
<entry>11:00</entry>
|
|
<entry>19:00</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</para>
|
|
<para>An example: Let's assume that someone in Los Angeles
|
|
captured a packet with Wireshark at exactly 2 o'clock local
|
|
time and sends you this capture file. The capture file's time
|
|
stamp will be represented in UTC as 10 o'clock. You are
|
|
located in Berlin and will see 11 o'clock on your Wireshark
|
|
display.</para>
|
|
<para>Now you have a phone call, video conference or Internet
|
|
meeting with that one to talk about that capture file. As you
|
|
are both looking at the displayed time on your local
|
|
computers, the one in Los Angeles still sees 2 o'clock but
|
|
you in Berlin will see 11 o'clock. The time displays are
|
|
different as both Wireshark displays will show the
|
|
(different) local times at the same point in time.</para>
|
|
<para>
|
|
<command>Conclusion</command>: You may not bother about the
|
|
date/time of the time stamp you currently look at, unless you
|
|
must make sure that the date/time is as expected. So, if you
|
|
get a capture file from a different time zone and/or DST,
|
|
you'll have to find out the time zone/DST difference between
|
|
the two local times and "mentally adjust" the time stamps
|
|
accordingly. In any case, make sure that every computer in
|
|
question has the correct time and time zone setting.</para>
|
|
</section>
|
|
</section>
|
|
<section id="ChAdvReassemblySection">
|
|
<title>Packet Reassembling</title>
|
|
<section>
|
|
<title>What is it?</title>
|
|
<para>Network protocols often need to transport large chunks
|
|
of data, which are complete in themselves, e.g. when transferring
|
|
a file. The underlying protocol might not be able to handle
|
|
that chunk size (e.g. limitation of the network packet size),
|
|
or is stream-based like TCP, which doesn't know data chunks
|
|
at all.</para>
|
|
<para>In that case the network protocol has to handle the
|
|
chunk boundaries itself and (if required) spread the data
|
|
over multiple packets. It obviously also needs a mechanism to
|
|
determine the chunk boundaries on the receiving side.</para>
|
|
<tip>
|
|
<title>Tip!</title>
|
|
<para>Wireshark calls this mechanism reassembling, although
|
|
a specific protocol specification might use a different
|
|
term for this (e.g. desegmentation, defragmentation,
|
|
...).</para>
|
|
</tip>
|
|
</section>
|
|
<section>
|
|
<title>How Wireshark handles it</title>
|
|
<para>For some of the network protocols Wireshark knows of, a
|
|
mechanism is implemented to find, decode and display these
|
|
chunks of data. Wireshark will try to find the corresponding
|
|
packets of this chunk, and will show the combined data as
|
|
additional pages in the "Packet Bytes" pane (for information
|
|
about this pane, see
|
|
<xref linkend="ChUsePacketBytesPaneSection" />).</para>
|
|
<para>
|
|
<figure id="ChAdvWiresharkBytesPaneTabs">
|
|
<title>The "Packet Bytes" pane with a reassembled
|
|
tab</title>
|
|
<graphic entityref="WiresharkBytesPaneTabs"
|
|
format="PNG" />
|
|
</figure>
|
|
</para>
|
|
<note>
|
|
<title>Note!</title>
|
|
<para>Reassembling might take place at several protocol
|
|
layers, so it's possible that multiple tabs in the "Packet
|
|
Bytes" pane appear.</para>
|
|
</note>
|
|
<note>
|
|
<title>Note!</title>
|
|
<para>You will find the reassembled data in the last packet
|
|
of the chunk.</para>
|
|
</note>
|
|
<para>An example: In a
|
|
<command>HTTP</command> GET response, the requested data (e.g.
|
|
an HTML page) is returned. Wireshark will show the hex dump of
|
|
the data in a new tab "Uncompressed entity body" in the
|
|
"Packet Bytes" pane.</para>
|
|
<para>Reassembling is enabled in the preferences by default.
|
|
The defaults were changed from disabled to enabled in
|
|
September 2005. If you created your preference settings
|
|
before this date, you might look if reassembling is actually
|
|
enabled, as it can be extremely helpful while analyzing
|
|
network packets.</para>
|
|
<para>The enabling or disabling of the reassemble settings of
|
|
a protocol typically requires two things:
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>the lower level protocol (e.g., TCP) must support
|
|
reassembly. Often this reassembly can be enabled or
|
|
disabled via the protocol preferences.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>the higher level protocol (e.g., HTTP) must use the
|
|
reassembly mechanism to reassemble fragmented protocol
|
|
data. This too can often be enabled or disabled via the
|
|
protocol preferences.</para>
|
|
</listitem>
|
|
</orderedlist></para>
|
|
<para>The tooltip of the higher level protocol setting will
|
|
notify you if and which lower level protocol setting also has to
|
|
be considered.</para>
|
|
</section>
|
|
</section>
|
|
<section id="ChAdvNameResolutionSection">
|
|
<title>Name Resolution</title>
|
|
<para>Name resolution tries to convert some of the numerical
|
|
address values into a human readable format. There are two
|
|
possible ways to do these conversions, depending on the
|
|
resolution to be done: calling system/network services (like
|
|
the <function>gethostname()</function> function) and/or resolve
|
|
from Wireshark specific configuration files. For details about the
|
|
configuration files Wireshark uses for name resolution and
|
|
alike, see <xref linkend="AppFiles" />.</para>
|
|
<para>The name resolution feature can be enabled individually
|
|
for the protocol layers listed in the following sections.</para>
|
|
<section>
|
|
<title>Name Resolution drawbacks</title>
|
|
<para>Name resolution can be invaluable while working with
|
|
Wireshark and may even save you hours of work. Unfortunately,
|
|
it also has its drawbacks.</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<command>Name resolution will often fail.</command> The
|
|
name to be resolved might simply be unknown by the name
|
|
servers asked, or the servers are just not available and
|
|
the name is also not found in Wireshark's configuration
|
|
files.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>The resolved names are not stored in the capture
|
|
file or somewhere else.</command> So the resolved names
|
|
might not be available if you open the capture file later
|
|
or on a different machine. Each time you open a capture
|
|
file it may look "slightly different", simply
|
|
because you can't connect to the name server (which you
|
|
could connect to before).</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>DNS may add additional packets to your capture
|
|
file.</command> You may see packets to/from your machine
|
|
in your capture file, which are caused by name resolution
|
|
network services of the machine Wireshark captures from.
|
|
XXX - are there any other such packets than DNS
|
|
ones?</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Resolved DNS names are cached by
|
|
Wireshark.</command> This is required for acceptable
|
|
performance. However, if the name resolution information
|
|
should change while Wireshark is running, Wireshark won't
|
|
notice a change in the name resolution information once
|
|
it gets cached. If this information changes while
|
|
Wireshark is running, e.g. a new DHCP lease takes effect,
|
|
Wireshark won't notice it. XXX - is this true for all or
|
|
only for DNS info?</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<tip>
|
|
<title>Tip!</title>
|
|
<para>The name resolution in the packet list is done while
|
|
the list is filled. If a name could be resolved after a
|
|
packet was added to the list, that former entry won't be
|
|
changed. As the name resolution results are cached, you can
|
|
use "View/Reload" to rebuild the packet list, this time
|
|
with the correctly resolved names. However, this isn't
|
|
possible while a capture is in progress.</para>
|
|
</tip>
|
|
</section>
|
|
<section>
|
|
<title>Ethernet name resolution (MAC layer)</title>
|
|
<para>Try to resolve an Ethernet MAC address (e.g.
|
|
00:09:5b:01:02:03) to something more "human readable".</para>
|
|
<para>
|
|
<command>ARP name resolution (system
|
|
service)</command>: Wireshark will ask the operating system to
|
|
convert an Ethernet address to the corresponding IP address
|
|
(e.g. 00:09:5b:01:02:03 → 192.168.0.1).</para>
|
|
<para>
|
|
<command>Ethernet codes (ethers file)</command>: If the ARP
|
|
name resolution failed, Wireshark tries to convert the
|
|
Ethernet address to a known device name, which has been
|
|
assigned by the user using an <filename>ethers</filename>
|
|
file (e.g. 00:09:5b:01:02:03 → homerouter).</para>
|
|
<para>
|
|
<command>Ethernet manufacturer codes (manuf file)</command>: If
|
|
neither ARP or ethers returns a result, Wireshark tries
|
|
to convert the first 3 bytes of an ethernet address to an
|
|
abbreviated manufacturer name, which has been assigned by the
|
|
IEEE (e.g. 00:09:5b:01:02:03 → Netgear_01:02:03).</para>
|
|
</section>
|
|
<section>
|
|
<title>IP name resolution (network layer)</title>
|
|
<para>Try to resolve an IP address (e.g. 216.239.37.99) to
|
|
something more "human readable".</para>
|
|
<para>
|
|
<command>DNS/concurrent DNS name resolution (system/library
|
|
service)</command>: Wireshark will ask the operating system
|
|
(or the concurrent DNS library), to convert an IP address to
|
|
the hostname associated with it (e.g. 216.239.37.99 →
|
|
www.1.google.com). The DNS service is using synchronous calls
|
|
to the DNS server. So Wireshark will stop responding until a
|
|
response to a DNS request is returned. If possible, you might
|
|
consider using the concurrent DNS library (which won't wait
|
|
for a name server response).</para>
|
|
<warning>
|
|
<title>Warning!</title>
|
|
<para>Enabling network name resolution when your name
|
|
server is unavailable may significantly slow down Wireshark
|
|
while it waits for all of the name server requests to time
|
|
out. Use concurrent DNS in that case.</para>
|
|
</warning>
|
|
<para>
|
|
<command>DNS vs. concurrent DNS</command>: here's a short
|
|
comparison:
|
|
Both mechanisms are used to convert an IP address to some
|
|
human readable (domain) name. The usual DNS call
|
|
<function>gethostname()</function> will try to convert the
|
|
address to a name. To do this, it will first ask the systems
|
|
hosts file (e.g. <filename>/etc/hosts</filename>) if it finds
|
|
a matching entry. If that fails, it will ask the configured
|
|
DNS server(s) about the name.</para>
|
|
<para>So the real difference between DNS and concurrent DNS
|
|
comes when the system has to wait for the DNS server about a
|
|
name resolution. The system call <function>gethostname()
|
|
</function> will wait until a name is resolved or an error
|
|
occurs. If the DNS server is unavailable, this might take
|
|
quite a while (several seconds).</para>
|
|
<para>The concurrent DNS service works a bit differently. It
|
|
will also ask the DNS server, but it won't wait for the
|
|
answer. It will just return to Wireshark in a very short
|
|
amount of time. The actual (and the following) address fields
|
|
won't show the resolved name until the DNS server returns an
|
|
answer. As mentioned above, the values get cached, so you can
|
|
use View/Reload to "update" these fields to show the resolved
|
|
values.</para>
|
|
<para>
|
|
<command>hosts name resolution (hosts file)</command>: If DNS
|
|
name resolution failed, Wireshark will try to convert an IP
|
|
address to the hostname associated with it, using a hosts
|
|
file provided by the user (e.g. 216.239.37.99 →
|
|
www.google.com).</para>
|
|
</section>
|
|
<section>
|
|
<title>IPX name resolution (network layer)</title>
|
|
<para>
|
|
<command>ipxnet name resolution (ipxnets file)</command>: XXX -
|
|
add ipxnets name resolution explanation.</para>
|
|
</section>
|
|
<section>
|
|
<title>TCP/UDP port name resolution (transport layer)</title>
|
|
<para>Try to resolve a TCP/UDP port (e.g. 80) to something
|
|
more "human readable".</para>
|
|
<para>
|
|
<command>TCP/UDP port conversion (system service)</command>:
|
|
Wireshark will ask the operating system to convert a TCP or
|
|
UDP port to its well known name (e.g. 80 → http).</para>
|
|
<para>XXX - mention the role of the /etc/services file (but
|
|
don't forget the files and folders section)!</para>
|
|
</section>
|
|
</section>
|
|
<section id="ChAdvChecksums">
|
|
<title>Checksums</title>
|
|
<para>Several network protocols use checksums to ensure data
|
|
integrity.</para>
|
|
<tip>
|
|
<title>Tip!</title>
|
|
<para>Applying checksums as described here is also known as
|
|
<command>redundancy checking</command>.</para>
|
|
</tip>
|
|
<sidebar>
|
|
<title>What are checksums for?</title>
|
|
<para>Checksums are used to ensure the integrity of data
|
|
portions for data transmission or storage. A checksum is
|
|
basically a calculated summary of such a data portion.</para>
|
|
<para>Network data transmissions often produce errors, such
|
|
as toggled, missing or duplicated bits. As a result, the data
|
|
received might not be identical to the data transmitted,
|
|
which is obviously a bad thing.</para>
|
|
<para>Because of these transmission errors, network protocols
|
|
very often use checksums to detect such errors. The
|
|
transmitter will calculate a checksum of the data and
|
|
transmits the data together with the checksum. The receiver
|
|
will calculate the checksum of the received data with the
|
|
same algorithm as the transmitter. If the received and
|
|
calculated checksums don't match a transmission error has
|
|
occurred.</para>
|
|
<para>Some checksum algorithms are able to recover (simple)
|
|
errors by calculating where the expected error must be and
|
|
repairing it.</para>
|
|
<para>If there are errors that cannot be recovered, the
|
|
receiving side throws away the packet. Depending on the
|
|
network protocol, this data loss is simply ignored or the
|
|
sending side needs to detect this loss somehow and
|
|
retransmits the required packet(s).</para>
|
|
<para>Using a checksum drastically reduces the number of
|
|
undetected transmission errors. However, the usual checksum
|
|
algorithms cannot guarantee an error detection of 100%, so a
|
|
very small number of transmission errors may remain
|
|
undetected.</para>
|
|
<para>There are several different kinds of checksum
|
|
algorithms; an example of an often used checksum algorithm is
|
|
CRC32. The checksum algorithm actually chosen for a specific
|
|
network protocol will depend on the expected error rate of
|
|
the network medium, the importance of error detection, the
|
|
processor load to perform the calculation, the performance
|
|
needed and many other things.</para>
|
|
<para>Further information about checksums can be found at:
|
|
<ulink url="&WikipediaWebsite;/wiki/Checksum" />.</para>
|
|
</sidebar>
|
|
<section>
|
|
<title>Wireshark checksum validation</title>
|
|
<para>Wireshark will validate the checksums of several
|
|
protocols, e.g.: IP, TCP, UDP, ...</para>
|
|
<para>It will do the same calculation as a "normal receiver"
|
|
would do, and shows the checksum fields in the packet details
|
|
with a comment, e.g.: [correct], [invalid, must be
|
|
0x12345678] or alike.</para>
|
|
<para>Checksum validation can be switched off for various
|
|
protocols in the Wireshark protocol preferences, e.g. to
|
|
(very slightly) increase performance.</para>
|
|
<para>If the checksum validation is enabled and it detected
|
|
an invalid checksum, features like packet reassembling won't
|
|
be processed. This is avoided as incorrect connection data
|
|
could "confuse" the internal database.</para>
|
|
</section>
|
|
<section>
|
|
<title>Checksum offloading</title>
|
|
<para>The checksum calculation might be done by the network
|
|
driver, protocol driver or even in hardware.</para>
|
|
<para>For example: The Ethernet transmitting hardware
|
|
calculates the Ethernet CRC32 checksum and the receiving
|
|
hardware validates this checksum. If the received checksum is
|
|
wrong Wireshark won't even see the packet, as the Ethernet
|
|
hardware internally throws away the packet.</para>
|
|
<para>Higher level checksums are "traditionally" calculated
|
|
by the protocol implementation and the completed packet is
|
|
then handed over to the hardware.</para>
|
|
<para>Recent network hardware can perform advanced features
|
|
such as IP checksum calculation, also known as checksum
|
|
offloading. The network driver won't calculate the checksum
|
|
itself but will simply hand over an empty (zero or garbage filled)
|
|
checksum field to the hardware.</para>
|
|
<note>
|
|
<title>Note!</title>
|
|
<para>Checksum offloading often causes confusion as the
|
|
network packets to be transmitted are handed over to
|
|
Wireshark before the checksums are actually calculated.
|
|
Wireshark gets these "empty" checksums and displays them as
|
|
invalid, even though the packets will contain valid
|
|
checksums when they leave the network hardware
|
|
later.</para>
|
|
</note>
|
|
<para>Checksum offloading can be confusing and having a lot
|
|
of [invalid] messages on the screen can be quite annoying. As
|
|
mentioned above, invalid checksums may lead to unreassembled
|
|
packets, making the analysis of the packet data much
|
|
harder.</para>
|
|
<para>You can do two things to avoid this checksum offloading
|
|
problem:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Turn off the checksum offloading in the network
|
|
driver, if this option is available.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Turn off checksum validation of the specific
|
|
protocol in the Wireshark preferences.</para>
|
|
</listitem>
|
|
</itemizedlist></para>
|
|
</section>
|
|
</section>
|
|
</chapter>
|
|
<!-- End of WSUG Chapter Advanced -->
|