forked from osmocom/wireshark
![Gerald Combs](/assets/img/avatar_default.png)
Leave most of the content intact for now. Change-Id: Ie91fda8a3fe6ea2eb4c47acf7c41d7e6979235b0 Reviewed-on: https://code.wireshark.org/review/3938 Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org> Reviewed-by: Gerald Combs <gerald@wireshark.org>
786 lines
32 KiB
Text
786 lines
32 KiB
Text
++++++++++++++++++++++++++++++++++++++
|
|
<!-- WSUG Chapter Advanced -->
|
|
++++++++++++++++++++++++++++++++++++++
|
|
|
|
[[ChapterAdvanced]]
|
|
|
|
== Advanced Topics
|
|
|
|
[[ChAdvIntroduction]]
|
|
|
|
=== Introduction
|
|
|
|
This chapter some of Wireshark's advanced features.
|
|
|
|
[[ChAdvFollowTCPSection]]
|
|
|
|
=== Following TCP streams
|
|
|
|
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.
|
|
|
|
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 <<ChAdvFollowStream>>.
|
|
|
|
[NOTE]
|
|
====
|
|
Opening the ``Follow TCP Stream'' installs a display filter to
|
|
select all the packets in the TCP stream you have selected.
|
|
====
|
|
|
|
==== The ``Follow TCP Stream'' dialog box
|
|
|
|
[[ChAdvFollowStream]]
|
|
|
|
.The ``Follow TCP Stream'' dialog box
|
|
image::wsug_graphics/ws-follow-stream.png[]
|
|
|
|
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
|
|
``Colors'' page if the ``Preferences'' dialog.
|
|
|
|
Non-printable characters will be replaced by dots.
|
|
|
|
// XXX - What about line wrapping (maximum line length) and CRNL conversions?
|
|
|
|
The stream content won't be updated while doing a live capture. To get the
|
|
latest content you'll have to reopen the dialog.
|
|
|
|
You can choose from the following actions:
|
|
|
|
. __Save As__: Save the stream data in the currently selected format.
|
|
|
|
. __Print__: Print the stream data in the currently selected format.
|
|
|
|
. __Direction__: Choose the stream direction to be displayed (``Entire
|
|
conversation'', ``data from A to B only'' or ``data from B to A only'').
|
|
|
|
. __Filter out this stream__: Apply a display filter removing the current TCP
|
|
stream data from the display.
|
|
|
|
. __Close__: Close this dialog box, leaving the current display filter in
|
|
effect.
|
|
|
|
You can choose to view the data in one of the following formats:
|
|
|
|
. __ASCII__: In this view you see the data from each direction in ASCII.
|
|
Obviously best for ASCII based protocols, e.g. HTTP.
|
|
|
|
. __EBCDIC__: For the big-iron freaks out there.
|
|
|
|
. __HEX Dump__: This allows you to see all the data. This will require a lot of
|
|
screen space and is best used with binary protocols.
|
|
|
|
. __C Arrays__: This allows you to import the stream data into your own C
|
|
program.
|
|
|
|
. __Raw__: 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.
|
|
|
|
[[ChAdvExpert]]
|
|
|
|
=== Expert Information
|
|
|
|
The expert infos is a kind of log of the anomalies found by Wireshark in a
|
|
capture file.
|
|
|
|
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'' .
|
|
|
|
[WARNING]
|
|
.Expert infos are only a hint
|
|
====
|
|
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.
|
|
====
|
|
|
|
The amount of expert infos largely depends on the protocol being used. While
|
|
some common protocols like TCP/IP will show detailed expert infos, most other
|
|
protocols currently won't show any expert infos at all.
|
|
|
|
The following will first describe the components of a single expert info, then
|
|
the User Interface.
|
|
|
|
[[ChAdvExpertInfoEntries]]
|
|
|
|
==== Expert Info Entries
|
|
|
|
Each expert info will contain the following things which will be described in
|
|
detail below.
|
|
|
|
[[ChAdvTabExpertInfoEntries]]
|
|
|
|
.Some example expert infos
|
|
[options="header"]
|
|
|===============
|
|
|Packet #|Severity|Group|Protocol|Summary
|
|
|1|Note|Sequence|TCP|Duplicate ACK (#1)
|
|
|2|Chat|Sequence|TCP|Connection reset (RST)
|
|
|8|Note|Sequence|TCP|Keep-Alive
|
|
|9|Warn|Sequence|TCP|Fast retransmission (suspected)
|
|
|===============
|
|
|
|
[[ChAdvExpertSeverity]]
|
|
|
|
===== Severity
|
|
|
|
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:
|
|
|
|
* __Chat (grey)__: information about usual workflow, e.g. a TCP packet with the
|
|
SYN flag set
|
|
|
|
* __Note (cyan)__: notable things, e.g. an application returned an ``usual''
|
|
error code like HTTP 404
|
|
|
|
* __Warn (yellow)__: warning, e.g. application returned an ``unusual'' error
|
|
code like a connection problem
|
|
|
|
* __Error (red)__: serious problem, e.g. [Malformed Packet]
|
|
|
|
[[ChAdvExpertGroup]]
|
|
|
|
===== Group
|
|
|
|
There are some common groups of expert infos. The following are currently implemented:
|
|
|
|
* __Checksum__: a checksum was invalid
|
|
|
|
* __Sequence__: protocol sequence suspicious, e.g. sequence wasn't continuous or
|
|
a retransmission was detected or ...
|
|
|
|
* __Response Code__: problem with application response code, e.g. HTTP 404 page
|
|
not found
|
|
|
|
* __Request Code__: an application request (e.g. File Handle == x), usually Chat
|
|
level
|
|
|
|
* __Undecoded__: dissector incomplete or data can't be decoded for other reasons
|
|
|
|
* __Reassemble__: problems while reassembling, e.g. not all fragments were
|
|
available or an exception happened while reassembling
|
|
|
|
* __Protocol__: violation of protocol specs (e.g. invalid field values or
|
|
illegal lengths), dissection of this packet is probably continued
|
|
|
|
* __Malformed__: malformed packet or dissector has a bug, dissection of this
|
|
packet aborted
|
|
|
|
* __Debug__: debugging (should not occur in release versions)
|
|
|
|
It's possible that more groups will be added in the future.
|
|
|
|
[[ChAdvExpertProtocol]]
|
|
|
|
===== Protocol
|
|
|
|
The protocol in which the expert info was caused.
|
|
|
|
[[ChAdvExpertSummary]]
|
|
|
|
===== Summary
|
|
|
|
Each expert info will also have a short additional text with some further explanation.
|
|
|
|
[[ChAdvExpertDialog]]
|
|
|
|
==== ``Expert Info'' dialog
|
|
|
|
You can open the expert info dialog by selecting menu:Analyze[Expert Info].
|
|
|
|
// XXX - add explanation of the dialogs context menu.
|
|
|
|
.The ``Expert Info'' dialog box
|
|
image::wsug_graphics/ws-expert-infos.png[]
|
|
|
|
[[ChAdvExpertDialogTabs]]
|
|
|
|
===== Errors / Warnings / Notes / Chats tabs
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
[[ChAdvExpertDialogDetails]]
|
|
|
|
===== Details tab
|
|
|
|
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.
|
|
|
|
[[ChAdvExpertColorizedTree]]
|
|
|
|
==== ``Colorized'' Protocol Details Tree
|
|
|
|
.The ``Colorized'' protocol details tree
|
|
image::wsug_graphics/ws-expert-colored-tree.png[]
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
[[ChAdvExpertColumn]]
|
|
|
|
==== ``Expert'' Packet List Column (optional)
|
|
|
|
.The ``Expert'' packet list column
|
|
image::wsug_graphics/ws-expert-column.png[]
|
|
|
|
An optional ``Expert Info Severity'' packet list column is available 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 <<ChCustPreferencesSection>>.
|
|
|
|
[[ChAdvTimestamps]]
|
|
|
|
=== Time Stamps
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
==== Wireshark internals
|
|
|
|
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
|
|
<<ChUseViewMenuSection>> for details.
|
|
|
|
While reading or writing capture files, Wireshark converts the time stamp data
|
|
between the capture file format and the internal format as required.
|
|
|
|
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.
|
|
|
|
==== Capture file formats
|
|
|
|
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).
|
|
|
|
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.
|
|
|
|
Writing data into a capture file format that doesn't provide the capability to
|
|
store the actual precision will lead to loss of information. For example, if you
|
|
load a capture file with nanosecond resolution and store the capture data in a
|
|
libpcap file (with microsecond resolution) Wireshark obviously must reduce the
|
|
precision from nanosecond to microsecond.
|
|
|
|
==== Accuracy
|
|
|
|
People often ask ``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, etc) that you use. Because of this, the
|
|
above question is difficult to answer in a general way.
|
|
|
|
[NOTE]
|
|
====
|
|
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.
|
|
|
|
Don't use USB connected NICs when you need precise time stamp
|
|
accuracy.
|
|
====
|
|
|
|
// (XXX - are there any such NIC's that generate time stamps on the USB
|
|
// hardware?)
|
|
|
|
[[ChAdvTimezones]]
|
|
|
|
=== Time Zones
|
|
|
|
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 ;-)
|
|
|
|
First of all, there are two reasons why you may not need to think about time
|
|
zones at all:
|
|
|
|
* 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).
|
|
|
|
* 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.
|
|
|
|
.What are time zones?
|
|
****
|
|
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.
|
|
|
|
For that reason, the earth is split into several different time zones, each zone
|
|
with a local time that corresponds to the local sunset.
|
|
|
|
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!
|
|
|
|
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''.
|
|
|
|
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)!
|
|
|
|
Further information can be found at:
|
|
link:wikipedia-web-site:[]Time_zone[wikipedia-web-site:[]Time_zone] and
|
|
link:wikipedia-web-site:[]Coordinated_Universal_Time[wikipedia-web-site:[]Coordinated_Universal_Time].
|
|
****
|
|
|
|
|
|
|
|
.What is daylight saving time (DST)?
|
|
****
|
|
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''.
|
|
|
|
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).
|
|
|
|
Keep in mind: UTC remains the same all year around, regardless of DST!
|
|
|
|
Further information can be found at
|
|
link:wikipedia-web-site:[]Daylight_saving[wikipedia-web-site:[]Daylight_saving].
|
|
****
|
|
|
|
Further time zone and DST information can be found at
|
|
link:greenwichmeantime-web-site:[][greenwichmeantime-web-site:[]] and
|
|
link:timeanddate-web-site:[][timeanddate-web-site:[]].
|
|
|
|
==== Set your computer's time correctly!
|
|
|
|
If you work with people around the world it's very helpful to set your
|
|
computer's time and time zone right.
|
|
|
|
You should set your computers time and time zone in the correct sequence:
|
|
|
|
. Set your time zone to your current location
|
|
|
|
. Set your computer's clock to the local time
|
|
|
|
This way you will tell your computer both the local time and also the time
|
|
offset to UTC. Many organizations simply set the time zone on their servers and
|
|
networking gear to UTC in order to make coordination and troubleshooting easier.
|
|
|
|
[TIP]
|
|
====
|
|
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.
|
|
====
|
|
|
|
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:
|
|
link:ntp-web-site:[][ntp-web-site:[]].
|
|
|
|
|
|
==== Wireshark and Time Zones
|
|
|
|
So what's the relationship between Wireshark and time zones anyway?
|
|
|
|
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 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. 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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
[[ChAdvTabTimezones]]
|
|
|
|
.Time zone examples for UTC arrival times (without DST)
|
|
[options="header"]
|
|
|===============
|
|
||Los Angeles|New York|Madrid|London|Berlin|Tokyo
|
|
|_Capture File (UTC)_|10:00|10:00|10:00|10:00|10:00|10:00
|
|
|_Local Offset to UTC_|-8|-5|-1|0|+1|+9
|
|
|_Displayed Time (Local Time)_|02:00|05:00|09:00|10:00|11:00|19:00
|
|
|===============
|
|
|
|
For 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.
|
|
|
|
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.
|
|
|
|
__Conclusion__: 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.
|
|
|
|
[[ChAdvReassemblySection]]
|
|
|
|
|
|
=== Packet Reassembly
|
|
|
|
==== What is it?
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Wireshark calls this mechanism reassembly, although a specific protocol
|
|
specification might use a different term for this (e.g. desegmentation,
|
|
defragmentation, etc).
|
|
|
|
==== How Wireshark handles it
|
|
|
|
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 <<ChUsePacketBytesPaneSection>>).
|
|
|
|
[[ChAdvWiresharkBytesPaneTabs]]
|
|
|
|
.The ``Packet Bytes'' pane with a reassembled tab
|
|
image::wsug_graphics/ws-bytes-pane-tabs.png[]
|
|
|
|
Reassembly might take place at several protocol layers, so it's possible that
|
|
multiple tabs in the ``Packet Bytes'' pane appear.
|
|
|
|
[NOTE]
|
|
====
|
|
You will find the reassembled data in the last packet of the chunk.
|
|
====
|
|
|
|
For example, in a _HTTP_ 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.
|
|
|
|
Reassembly is enabled in the preferences by default but can be disabled in the
|
|
preferences for the protocol in question. Enabling or disabling reassembly
|
|
settings for a protocol typically requires two things:
|
|
|
|
. The lower level protocol (e.g., TCP) must support reassembly. Often this
|
|
reassembly can be enabled or disabled via the protocol preferences.
|
|
|
|
. 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.
|
|
|
|
The tooltip of the higher level protocol setting will notify you if and which
|
|
lower level protocol setting also has to be considered.
|
|
|
|
[[ChAdvNameResolutionSection]]
|
|
|
|
=== Name Resolution
|
|
|
|
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 gethostname() function) and/or resolve from Wireshark specific configuration
|
|
files. For details about the configuration files Wireshark uses for name
|
|
resolution and alike, see <<AppFiles>>.
|
|
|
|
The name resolution feature can be enabled individually for the protocol layers
|
|
listed in the following sections.
|
|
|
|
==== Name Resolution drawbacks
|
|
|
|
Name resolution can be invaluable while working with Wireshark and may even save
|
|
you hours of work. Unfortunately, it also has its drawbacks.
|
|
|
|
* _Name resolution will often fail._ 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.
|
|
|
|
* _The resolved names are not stored in the capture file or somewhere else._ 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).
|
|
|
|
* _DNS may add additional packets to your capture file._ 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?
|
|
|
|
* _Resolved DNS names are cached by Wireshark._ 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?
|
|
|
|
Name resolution in the packet list is done while the list is filled. If a name
|
|
can be resolved after a packet is added to the list, its former entry won't be
|
|
changed. As the name resolution results are cached, you can use
|
|
menu:View[Reload] to rebuild the packet list with the correctly resolved names.
|
|
However, this isn't possible while a capture is in progress.
|
|
|
|
==== Ethernet name resolution (MAC layer)
|
|
|
|
Try to resolve an Ethernet MAC address (e.g. 00:09:5b:01:02:03) to something
|
|
more ``human readable''.
|
|
|
|
__ARP name resolution (system service)__: 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).
|
|
|
|
__Ethernet codes (ethers file)__: 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 _ethers_ file (e.g. 00:09:5b:01:02:03 →
|
|
homerouter).
|
|
|
|
__Ethernet manufacturer codes (manuf file)__: 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).
|
|
|
|
==== IP name resolution (network layer)
|
|
|
|
Try to resolve an IP address (e.g. 216.239.37.99) to something more ``human
|
|
readable''.
|
|
|
|
__DNS/concurrent DNS name resolution (system/library service)__: 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).
|
|
|
|
[WARNING]
|
|
====
|
|
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. Always use concurrent DNS resolution.
|
|
====
|
|
|
|
__DNS vs. concurrent DNS__: here's a short comparison: Both mechanisms are used
|
|
to convert an IP address to some human readable (domain) name. The usual DNS
|
|
call gethostname() will try to convert the address to a name. To do this, it
|
|
will first ask the systems hosts file (e.g. __/etc/hosts__) if it finds a
|
|
matching entry. If that fails, it will ask the configured DNS server(s) about
|
|
the name.
|
|
|
|
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
|
|
gethostname() 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).
|
|
|
|
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 menu:View[Reload] to ``update'' these
|
|
fields to show the resolved values.
|
|
|
|
__hosts name resolution (hosts file)__: 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).
|
|
|
|
==== TCP/UDP port name resolution (transport layer)
|
|
|
|
Try to resolve a TCP/UDP port (e.g. 80) to something more ``human readable''.
|
|
|
|
__TCP/UDP port conversion (system service)__: Wireshark will ask the operating
|
|
system to convert a TCP or UDP port to its well known name (e.g. 80 -> http).
|
|
|
|
// XXX - mention the role of the /etc/services file (but don't forget the files and folders section)!
|
|
|
|
[[ChAdvChecksums]]
|
|
|
|
=== Checksums
|
|
|
|
Several network protocols use checksums to ensure data integrity. Applying
|
|
checksums as described here is also known as _redundancy checking_.
|
|
|
|
|
|
.What are checksums for?
|
|
****
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Some checksum algorithms are able to recover (simple) errors by calculating
|
|
where the expected error must be and repairing it.
|
|
|
|
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).
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Further information about checksums can be found at:
|
|
link:wikipedia-web-site:[]Checksum[wikipedia-web-site:[]Checksum].
|
|
****
|
|
|
|
==== Wireshark checksum validation
|
|
|
|
Wireshark will validate the checksums of many protocols, e.g. IP, TCP, UDP, etc.
|
|
|
|
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] or
|
|
[invalid, must be 0x12345678].
|
|
|
|
Checksum validation can be switched off for various protocols in the Wireshark
|
|
protocol preferences, e.g. to (very slightly) increase performance.
|
|
|
|
If the checksum validation is enabled and it detected an invalid checksum,
|
|
features like packet reassembly won't be processed. This is avoided as
|
|
incorrect connection data could ``confuse'' the internal database.
|
|
|
|
==== Checksum offloading
|
|
|
|
The checksum calculation might be done by the network driver, protocol driver or
|
|
even in hardware.
|
|
|
|
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.
|
|
|
|
Higher level checksums are ``traditionally'' calculated by the protocol
|
|
implementation and the completed packet is then handed over to the hardware.
|
|
|
|
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.
|
|
|
|
|
|
[NOTE]
|
|
====
|
|
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.
|
|
====
|
|
|
|
|
|
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.
|
|
|
|
You can do two things to avoid this checksum offloading problem:
|
|
|
|
* Turn off the checksum offloading in the network driver, if this option is available.
|
|
|
|
* Turn off checksum validation of the specific protocol in the Wireshark preferences.
|
|
Recent releases of Wireshark disable checksum validation by default due to the
|
|
prevalance of offloading in modern hardware and operating systems.
|
|
|
|
++++++++++++++++++++++++++++++++++++++
|
|
<!-- End of WSUG Chapter Advanced -->
|
|
++++++++++++++++++++++++++++++++++++++ |