Advanced TopicsIntroductionIn this chapter some of the advanced features of
Wireshark will be described.Following TCP streamsIf 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
.Note!It is worthwhile noting that Follow TCP Stream installs
a display filter to select all the packets in the TCP stream
you have selected.The "Follow TCP Stream" dialog boxThe "Follow TCP Stream" dialog boxThe 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.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.Expert InfosThe 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" .Expert infos are only a hint!Take expert infos as a hint what's worth looking at,
but not more. For example: The absense 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.Expert Info EntriesEach expert info will contain the following things
which will be described in detail below:
Some example expert infosPacket #SeverityGroupProtocolSummary1NoteSequenceTCPDuplicate ACK (#1)2ChatSequenceTCPConnection reset (RST)8NoteSequenceTCPKeep-Alive9WarnSequenceTCPFast retransmission (suspected)
SeverityEvery 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
setNote (cyan): notable things, e.g. an
application returned an "usual" error code like HTTP
404Warn (yellow): warning, e.g.
application returned an "unusual" error code like a
connection problemError (red): serious problem, e.g.
[Malformed Packet]GroupThere are some common groups of expert infos. The
following are currently implemented:
Checksum: a checksum was
invalidSequence: 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
foundRequest Code: an application request
(e.g. File Handle == x), usually Chat levelUndecoded: dissector incomplete or
data can't be decoded for other reasonsReassemble: problems while
reassembling, e.g. not all fragments were available or
an exception happened while reassemblingMalformed: malformed packet or
dissector has a bug, dissection of this packet
abortedDebug: debugging (should not occur in
release versions)It's possible that more such group values
will be added in the future ...ProtocolThe protocol in which the expert info was
caused.SummaryEach expert info will also have a short additional
text with some further explanation."Expert Info Composite" dialogFrom the main menu you can open the expert info dialog,
using: "Analyze/Expert Info Composite"XXX - "Analyze/Expert Info" also exists but is
subject to removal and therefore not explained here.XXX - add explanation of the dialogs context
menu.Errors / Warnings / Notes / Chats tabsAn 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.Details tabThe 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."Colorized" Protocol Details TreeThe 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."Expert" Packet List Column (optional)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
.Time StampsTime 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 internalsThe 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
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 formatsEvery 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.Note!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.AccuracyIt'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!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.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?)Time ZonesIf 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:
&WikipediaTimezone; and
&WikipediaUTC;.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:
&WikipediaDaylightSaving;.Further time zone and DST information can be found at:
&TimezoneGMTSite; and
&TimezoneWorldClockSite;.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 locationSet your computer's clock to the local timeThis way you will tell your computer both the
local time and also the time offset to UTC.
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!Tip!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:
&NTPSite;.Wireshark and Time ZonesSo 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 (Windows NT 4.0, Windows 2000,
Windows XP, Windows Server 2003, Windows Vista) 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.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.
Time zone examples for UTC arrival times (without
DST)Los AngelesNew YorkMadridLondonBerlinTokyoCapture File (UTC)10:0010:0010:0010:0010:0010:00Local Offset to UTC-8-5-10+1+9Displayed Time (Local Time)02:0005:0009:0010:0011:0019:00
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.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.Packet ReassemblingWhat 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.Tip!Wireshark calls this mechanism reassembling, although
a specific protocol specification might use a different
term for this (e.g. desegmentation, defragmentation,
...).How Wireshark handles itFor 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
).The "Packet Bytes" pane with a reassembled
tabNote!Reassembling 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.An 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.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.The enabling or disabling of the reassemble settings of
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.Name ResolutionName resolution tries to resolve some of the numerical
address values into a human readable format. There are two
possible ways to do these conversations, depending on the
resolution to be done: calling system/network services (like
the gethostname function) and/or evaluate from Wireshark
specific configuration files. For details about the
configuration files Wireshark uses for name resolution and
alike, see
.The name resolution feature can be en-/disabled
separately for the protocol layers of the following
sections.Name Resolution drawbacksName 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", maybe simply
because you can't connect to a name server (which you
could connect 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 to 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?Tip!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.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/ADNS name resolution (system/library
service): Wireshark will ask the operating system (or
the ADNS 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 ADNS library (which won't wait for a
network 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. Use ADNS in that case.DNS vs. ADNS: 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 ADNS 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 ADNS service will work 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 ADNS call returned. As mentioned
above, the values get cached, so you can use 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).IPX name resolution (network layer)ipxnet name resolution (ipxnets file): XXX -
add ipxnets name resolution explanation.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)!ChecksumsSeveral network protocols use checksums to ensure data
integrity.Tip!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:
.Wireshark checksum validationWireshark will validate the checksums of several
protocols, e.g.: IP, TCP, UDP, ...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.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 reassembling won't
be processed. This is avoided as incorrect connection data
could "confuse" the internal database.Checksum offloadingThe 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.