776 lines
28 KiB
XML
776 lines
28 KiB
XML
<!-- EUG Chapter Advanced -->
|
|
|
|
<!-- $Id: -->
|
|
|
|
<chapter id="ChapterAdvanced">
|
|
<title>Advanced Topics</title>
|
|
|
|
<section id="ChAdvIntroduction"><title>Introduction</title>
|
|
<para>
|
|
In this chapter some advanced features of Ethereal will be described.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="ChAdvFollowTCPSection"><title>Following TCP streams</title>
|
|
<para>
|
|
There will be occasions when you would like to see the data from a TCP
|
|
session in the order 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. If so, Ethereal's ability to
|
|
follow a TCP stream will be useful to you.
|
|
</para>
|
|
<para>
|
|
Simply select a TCP packet in the stream/connection you are interested
|
|
in and then select the Follow TCP Stream menu item from the Ethereal
|
|
Tools menu. Ethereal will pop up a separate window with all the data
|
|
from the TCP stream laid out in order, as shown in
|
|
<xref linkend="ChAdvFollowStream"/>.
|
|
</para>
|
|
<section><title>The "Follow TCP stream" dialog box </title>
|
|
<figure id="ChAdvFollowStream">
|
|
<title>The "Follow TCP Stream" dialog box</title>
|
|
<graphic entityref="EtherealFollowStream" format="PNG"/>
|
|
</figure>
|
|
<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.
|
|
</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</para>
|
|
<para>
|
|
You can then 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 end in ASCII, but alternating according to when each
|
|
end sent data. Unfortunately, non-printing characters do not
|
|
print.
|
|
</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, but you lose the ability to read it in ASCII.
|
|
</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.
|
|
</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</para>
|
|
<note>
|
|
<title>Note!</title>
|
|
<para>
|
|
It is worthwhile noting that Follow TCP Stream installs a filter
|
|
to select all the packets in the TCP stream you have selected.
|
|
</para>
|
|
</note>
|
|
</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 what's going
|
|
on while Ethereal 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 will be
|
|
available for (later) analysis.
|
|
</para>
|
|
<para>
|
|
So where do these time stamps come from?
|
|
While capturing, Ethereal gets the time stamps from the libpcap (WinPcap)
|
|
library, which in turn get's them from the operating system kernel.
|
|
If the capture data is loaded from a capture file, Ethereal obviously gets
|
|
the data from that file.
|
|
</para>
|
|
<section><title>Ethereal internals</title>
|
|
<para>
|
|
The internal format that Ethereal 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 Ethereal displays the time stamp data
|
|
in the packet list, see <xref linkend="ChUseViewMenuSection"/> for details.
|
|
</para>
|
|
<para>
|
|
While reading or writing capture files, Ethereal converts the time stamp
|
|
data between the capture file format and the internal format as required.
|
|
</para>
|
|
<para>
|
|
While capturing, Ethereal 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 Ethereal knows support 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" (or even beyond?).
|
|
Most file formats store the time stamps with a fixed precision
|
|
(e.g. microseconds), while some file formats are even capable to store the
|
|
time stamp precision itself (whatever the benefit may be).
|
|
</para>
|
|
<para>
|
|
The common libpcap capture file format that is used by Ethereal (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)
|
|
Ethereal 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 Ethereal?".
|
|
Well, Ethereal doesn't create any time stamps itself but simply get's 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 stamps already
|
|
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 than 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 splitted 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 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 an 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 correct!</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
|
|
Ethereal supports (and for a lot more), for examples see:
|
|
<ulink url="&NTPSite;">&NTPSite;</ulink>.
|
|
</para>
|
|
</tip>
|
|
</para>
|
|
</section>
|
|
<section><title>Ethereal and Time Zones</title>
|
|
<para>
|
|
So what's the relationship between Ethereal and time zones anyway?
|
|
</para>
|
|
<para>
|
|
All capture file formats known save the time stamps in UTC format. The
|
|
capturing computer may have to convert the time stamps from local time to
|
|
UTC before it saves them to the capture file.
|
|
</para>
|
|
<para>
|
|
Ethereal 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.
|
|
</para>
|
|
<para>
|
|
<table id="ChAdvTabTimezones" frame="none">
|
|
<title>Time zone examples (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 at exactly 2
|
|
o'clock local time and sents 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 Ethereal 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 Ethereal 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>
|
|
Often network protocols needs to transport large chunks of data, which are
|
|
complete in itself, 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 that chunks itself and
|
|
(if required) spreading the data over multiple packets. It also needs a
|
|
mechanism to find back the chunk boundaries on the receiving side.
|
|
</para>
|
|
<tip><title>Tip!</title>
|
|
<para>
|
|
Ethereal calls this mechanism reassembling, although a specific protocol
|
|
specification might use a different term for this.
|
|
</para>
|
|
</tip>
|
|
</section>
|
|
<section><title>How Ethereal handles it</title>
|
|
<para>
|
|
For some of the network protocols Ethereal knows of, a mechanism is
|
|
implemented to find, decode and display these chunks of data.
|
|
Ethereal will try to find the corresponding packets of this chunk,
|
|
and will show the combined data as additional pages in the
|
|
"Packet Bytes" pane, see <xref linkend="ChUsePacketBytesPaneSection"/>.
|
|
</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. a
|
|
HTML page) is returned. Ethereal 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 note you if and
|
|
which lower level protocol setting has to be considered too.
|
|
</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="ChAdvNameResolutionSection"><title>Name Resolution</title>
|
|
<para>
|
|
Name resolution tries to resolve some of the numerical address values to
|
|
human readable names. There are two possible ways to do this
|
|
conversations, depending on the resolution to be done: calling
|
|
system/network services (like the gethostname function) and/or evaluate
|
|
from Ethereal specific configuration files. If there are both features
|
|
available, Ethereal will first try the system services and then fall back
|
|
to it's own configuration files. XXX - is this really true? For details
|
|
about the configuration files Ethereal uses for name resolution and alike,
|
|
see <xref linkend="AppFiles"/>.
|
|
</para>
|
|
<para>
|
|
However, be prepared that this conversion often will fail, e.g. the name
|
|
to be resolved might simply be unknown by the servers asked and not found
|
|
in the configuration files.
|
|
</para>
|
|
<note><title>Note!</title>
|
|
<para>
|
|
You may see packets to/from your machine in your capture file, which are
|
|
caused by name resolution network services (e.g. DNS packets).
|
|
</para>
|
|
</note>
|
|
<note><title>Note!</title>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</note>
|
|
<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
|
|
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.
|
|
</para>
|
|
</tip>
|
|
<para>
|
|
The name resolution feature can be en-/disabled separately for the
|
|
following protocol layers (in brackets):
|
|
</para>
|
|
<section><title>Ethernet name resolution (MAC layer)</title>
|
|
<para><command>ARP name resolution (system service)</command>
|
|
Ethereal 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, Ethereal 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).
|
|
</para>
|
|
<para><command>Ethernet manufacturer codes (manuf file)</command>
|
|
If both ARP and ethers didn't returned a result, Ethereal tries to convert
|
|
the first 3 bytes of an ethernet address to an abbreviated manufacturer name,
|
|
which has been assigned by the IEC
|
|
(e.g. 00:09:5b:01:02:03 -> Netgear_01:02:03).
|
|
</para>
|
|
</section>
|
|
<section><title>IP name resolution (network layer)</title>
|
|
<para><command>DNS/ADNS name resolution (system/library service)</command>
|
|
Ethereal will ask the operating system (or the ADNS library),
|
|
to convert an IP address to the hostname associated with it
|
|
(e.g. 65.208.228.223 -> www.ethereal.com). The DNS service is using
|
|
synchronous calls to the DNS server. So Ethereal 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).
|
|
</para>
|
|
<warning>
|
|
<title>Warning!</title>
|
|
<para>
|
|
Enabling network name resolution when your name server is
|
|
unavailable may significantly slow down Ethereal while it waits
|
|
for all of the name server requests to time out. Use ADNS in that
|
|
case.
|
|
</para>
|
|
</warning>
|
|
<para>
|
|
<command>DNS vs. ADNS</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 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.
|
|
</para>
|
|
<para>
|
|
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 Ethereal in a very short amount of time.
|
|
XXX - what does happen with the actual address field at that run? Will the
|
|
response be ignored for that field?
|
|
</para>
|
|
<para><command>hosts name resolution (hosts file)</command>
|
|
If DNS name resolution failed, Ethereal will try to convert an IP address
|
|
to the hostname associated with it, using an hosts file provided by the
|
|
user (e.g. 65.208.228.223 -> www.ethereal.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><command>TCP/UDP port conversion (system service)</command>
|
|
Ethereal will ask the operating system to convert a TCP or UDP port to
|
|
its well known name (e.g. 80 -> http).
|
|
</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 check</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 occured.
|
|
</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 can be found at:
|
|
<ulink url="http://en.wikipedia.org/wiki/Checksum"/>.
|
|
</para>
|
|
</sidebar>
|
|
<section><title>Ethereal checksum validation</title>
|
|
<para>
|
|
Ethereal will validate the checksums of several potocols, e.g.: IP, TCP, ...
|
|
</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
|
|
Ethereal 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 calculation / validation in hardware</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 Ethereal 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 simply hand
|
|
over an empty (usually zero 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 Ethereal before the checksums are actually
|
|
calculated.
|
|
Ethereal 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>
|
|
<tip><title>Tip!</title>
|
|
<para>
|
|
The term used for checksum offloading varies between manufacturers, so
|
|
you may find slightly different terms in the documentation and elsewhere.
|
|
</para>
|
|
</tip>
|
|
<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 Ethereal
|
|
preferences.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</section>
|
|
</section>
|
|
|
|
</chapter>
|
|
<!-- End of EUG Chapter Advanced -->
|
|
|