EUG -> WSUG

svn path=/trunk/; revision=18256

1 files changed, 897 insertions, 0 deletions

diff --git a/docbook/wsug_src/WSUG_chapter_advanced.xml b/docbook/wsug_src/WSUG_chapter_advanced.xml
new file mode 100644
index 0000000000..9df23cfe37
--- /dev/null
+++ b/docbook/wsug_src/WSUG_chapter_advanced.xml
@@ -0,0 +1,897 @@
+<!-- WSUG Chapter Advanced -->
+
+<!-- $Id:$ -->
+
+<chapter id="ChapterAdvanced">
+  <title>Advanced Topics</title>
+  
+  <section id="ChAdvIntroduction"><title>Introduction</title>
+  <para>
+  In this chapter some of the advanced features of Ethereal will be described.
+  </para>
+  </section>
+  
+  <section id="ChAdvFollowTCPSection"><title>Following TCP streams</title>
+    <para>
+	  If you are working with TCP based protocols it can be very helpful
+      to see the data from a TCP stream in the way that the application 
+	  layer sees it. 
+	  Perhaps you are looking for passwords in a Telnet stream, or you 
+	  are trying to make sense of a data stream.
+	  Maybe you just need a display filter to show only the packets of that 
+	  TCP stream.
+	  If so, Ethereal's ability to follow a TCP stream will be useful to you. 
+    </para>
+    <para>
+      Simply select a TCP packet in the packet list of the stream/connection 
+	  you are interested in and then select the Follow TCP Stream menu item 
+	  from the Wireshark Tools menu (or use the context menu in the packet 
+	  list).
+	  Ethereal will set an appropriate display filter and pop up a dialog
+	  box with all the data from the TCP stream laid out in order, 
+	  as shown in <xref linkend="ChAdvFollowStream"/>.
+    </para>
+    <note>
+      <title>Note!</title>
+      <para>
+	It is worthwhile noting that Follow TCP Stream installs a display filter 
+	to select all the packets in the TCP stream you have selected.
+      </para>
+    </note>
+	<section><title>The "Follow TCP Stream" dialog box </title>
+    <figure id="ChAdvFollowStream">
+      <title>The "Follow TCP Stream" dialog box</title>
+      <graphic entityref="EtherealFollowStream" format="PNG"/>
+    </figure>
+    <para>
+	The stream content is displayed in the same sequence as it appeared on 
+	the network. 
+	Traffic from A to B is marked in red, while traffic from B to A is 
+	marked in blue. 
+	If you like, you can change these colors in the Edit/Preferences 
+	"Colors" page.
+    </para>
+    <para>
+	None printable characters will be replaced by dots.
+	XXX - What about line wrapping (maximum line length) and CRNL conversions?
+    </para>
+    <para>
+	The stream content won't be updated while doing a live capture. 
+	To get the latest content you'll have to reopen the dialog.
+    </para>
+    <para>
+      You can choose from the following actions:
+      <orderedlist>
+	<listitem>
+	  <para>
+	    <command>Save As</command> Save the stream data in the currently
+		selected format.
+	  </para>
+	</listitem>
+	<listitem>
+	  <para>
+	    <command>Print</command> Print the stream data in the currently
+		selected format.
+	  </para>
+	</listitem>
+	<listitem>
+	  <para>
+	    <command>Direction</command> Choose the stream direction to be 
+		displayed ("Entire conversation", "data from A to B only" or "data 
+		from B to A only").
+	  </para>
+	</listitem>
+	<listitem>
+	  <para>
+	    <command>Filter out this stream</command> Apply a display filter 
+		removing the current TCP stream data from the display.
+	  </para>
+	</listitem>
+	<listitem>
+	  <para>
+	    <command>Close</command> Close this dialog box, leaving the current 
+		display filter in effect.
+	  </para>
+	</listitem>
+      </orderedlist>
+    </para>
+    <para>
+      You can choose to view the data in one of the following formats:
+      <orderedlist>
+	<listitem>
+	  <para>
+	    <command>ASCII</command>. In this view you see the data from 
+	    each direction in ASCII. Obviously best for ASCII based protocols, 
+		e.g. HTTP.
+	  </para>
+	</listitem>
+	<listitem>
+	  <para>
+	    <command>EBCDIC</command>. For the big-iron freaks out there.
+	  </para>
+	</listitem>
+	<listitem>
+	  <para>
+	    <command>HEX Dump</command>. This allows you to see all the 
+	    data. 
+		This will require a lot of screen space and is best used with 
+		binary protocols.
+	  </para>
+	</listitem>
+	<listitem>
+	  <para>
+	    <command>C Arrays</command>. This allows you to import the stream data
+		into your own C program.
+	  </para>
+	</listitem>
+	<listitem>
+	  <para>
+	    <command>Raw</command>. This allows you to load the unaltered stream 
+		data into a different program for further examination. 
+		The display will look the same as the ASCII setting, but "Save As" 
+		will result in a binary file.
+	  </para>
+	</listitem>
+      </orderedlist>
+    </para>
+  </section>
+  </section>
+
+  <section id="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 also 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 the "Time Display Format" item in the 
+	<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". 
+	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 Wireshark (and a 
+	lot of other tools) supports a fixed microsecond resolution "0.123456" 
+	only. 
+	</para>
+    <note>
+      <title>Note!</title>
+      <para>
+	  Writing data into a capture file format that doesn't provide
+	  the capability to store the actual precision will lead to loss of information.
+	  Example: If you load a capture file with nanosecond resolution and 
+	  store the capture data to a libpcap file (with microsecond resolution)
+	  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 Wireshark?". 
+	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 split into several different time zones, 
+	each zone with a local time that corresponds to the local sunset.
+	</para>
+	<para>
+	The time zone's base time is UTC (Coordinated Universal Time) or Zulu 
+	Time (military and aviation). The older term GMT (Greenwich Mean Time) 
+	shouldn't be used as it is slightly incorrect (up to 0.9 seconds 
+	difference to UTC). 
+	The UTC base time equals to 0 (based at Greenwich, England) and all 
+	time zones have an offset to UTC between -12 to +14 hours!
+	</para>
+	<para>
+	For example: If you live in 
+	Berlin you are in a time zone one hour earlier than UTC, so you are in 
+	time zone "+1" (time difference in hours compared to UTC). If it's 
+	3 o'clock in Berlin it's 2 o'clock in UTC "at the same moment".
+	</para>
+	<para>
+	Be aware that at a few places on earth don't use time zones with even 
+	hour offsets (e.g. New Delhi uses UTC+05:30)!
+	</para>
+	<para>
+	Further information can be found at: 
+	<ulink url="&WikipediaTimezone;">&WikipediaTimezone;</ulink> and 
+	<ulink url="&WikipediaUTC;">&WikipediaUTC;</ulink>.
+	</para>
+	
+	</sidebar>
+	<sidebar><title>What is daylight saving time (DST)?</title>
+	<para>
+	Daylight Saving Time (DST), also known as Summer Time, is intended to 
+	"save" some daylight during the summer months. 
+	To do this, a lot of countries (but not all!) add 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>
+	Ethereal'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 Ethereal. 
+	If the system's time zone is not set correctly, that conversion will 
+	not be done correctly.
+	</para>
+	<para>
+	Other capture file formats, such as the Microsoft Network
+	Monitor, DOS-based Sniffer, and Network Instruments Observer
+	formats, save the arrival time of packets as local time values.
+	</para>
+	<para>
+	Internally to Ethereal, time stamps are represented in UTC; this
+	means that, when reading capture files that save the arrival
+	time of packets as local time values, Ethereal must convert
+	those local time values to UTC values.
+	</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.  For capture files
+	saving the arrival time of packets as UTC values, this means
+	that the arrival time will be displayed as the local time in
+	your time zone, which might not be the same as the arrival time
+	in the time zone in which the packet was captured.  For capture
+	files saving the arrival time of packets as local time values,
+	the conversion to UTC will be done using your time zone's offset
+	from UTC and DST rules, which means the conversion will not be
+	done correctly; the conversion back to local time for display
+	might undo this correctly, in which case the arrival time will
+	be displayed as the arrival time in which the packet was
+	captured.
+	</para>
+	<para>
+    <table id="ChAdvTabTimezones" frame="none">
+      <title>Time zone examples for UTC arrival times (without DST)</title>
+      <tgroup cols="7">
+<!--	<colspec colnum="1" colwidth="72pt"/>
+	  <colspec colnum="2" colwidth="80pt"/>
+	  <colspec colnum="3" colwidth="80pt"/>-->
+	    <thead>
+	      <row>
+		<entry></entry>
+		<entry>Los Angeles</entry>
+		<entry>New York</entry>
+		<entry>Madrid</entry>
+		<entry>London</entry>
+		<entry>Berlin</entry>
+		<entry>Tokyo</entry>
+	      </row>
+	    </thead>
+	    <tbody>
+	      <row>
+		<entry><command>Capture File (UTC)</command></entry>
+		<entry>10:00</entry>
+		<entry>10:00</entry>
+		<entry>10:00</entry>
+		<entry>10:00</entry>
+		<entry>10:00</entry>
+		<entry>10:00</entry>
+	      </row>
+	      <row>
+		<entry><command>Local Offset to UTC</command></entry>
+		<entry>-8</entry>
+		<entry>-5</entry>
+		<entry>-1</entry>
+		<entry>0</entry>
+		<entry>+1</entry>
+		<entry>+9</entry>
+	      </row>
+	      <row>
+		<entry><command>Displayed Time (Local Time)</command></entry>
+		<entry>02:00</entry>
+		<entry>05:00</entry>
+		<entry>09:00</entry>
+		<entry>10:00</entry>
+		<entry>11:00</entry>
+		<entry>19:00</entry>
+	      </row>
+	    </tbody>
+      </tgroup>
+    </table>
+	</para>
+	<para>
+	An example:
+	Let's assume that someone in Los Angeles captured a packet with
+	Ethereal 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>
+	Network protocols often need 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 chunk boundaries 
+	itself and (if required) spreading the data over multiple packets. 
+	It obviously 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 (e.g. desegmentation, 
+	defragmentation, ...).
+	</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
+	(for information about this pane, see <xref 
+	linkend="ChUsePacketBytesPaneSection"/>).
+    </para>
+    <para>
+    <figure id="ChAdvEtherealBytesPaneTabs">
+      <title>The "Packet Bytes" pane with a reassembled tab</title>
+      <graphic entityref="EtherealBytesPaneTabs" format="PNG"/>
+    </figure>
+    </para>
+	
+    <note><title>Note!</title>
+    <para>
+	Reassembling might take place at several protocol layers, so it's possible 
+	that multiple tabs in the "Packet Bytes" pane appear.
+	</para>
+    </note>
+    <note><title>Note!</title>
+    <para>
+	You will find the reassembled data in the last packet of the chunk.
+	</para>
+    </note>
+    <para>
+	An example:
+		In a <command>HTTP</command> GET response, the requested data (e.g. 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 into 
+	a human readable format. 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. 
+	For details about the configuration files Ethereal uses for name 
+	resolution and alike, see <xref linkend="AppFiles"/>.
+	</para>
+    <para>
+	The name resolution feature can be en-/disabled separately for the 
+	protocol layers of the following sections.
+    </para>
+	
+	<section><title>Name Resolution drawbacks</title>
+    <para>
+	Name resolution can be invaluable while working with Ethereal and may 
+	save you even hours of work. Unfortunately, it also has it's drawbacks.
+    </para>
+      <itemizedlist>
+	<listitem>
+	<para>
+	<command>Name resolution will often fail.</command> The name to be 
+	resolved might simply be unknown by the name servers asked or the servers 
+	are just not available and the name is also not found in Wireshark's 
+	configuration files.
+    </para>
+	</listitem>
+	<listitem>
+    <para>
+	<command>The resolved names are not stored in the capture file or 
+	somewhere else.</command>
+	So the resolved names might not be available if you open the capture file
+	later or on a different machine.
+	Each time you open a capture file it may look "slightly different", 
+	maybe simply because you can't connect a name server (which you could 
+	connect before).
+    </para>
+	</listitem>
+	<listitem>
+    <para>
+	<command>DNS may add additional packets to your capture file.</command>
+	You may see packets to/from your machine in your capture file, which are
+	caused by name resolution network services of the machine Ethereal 
+	captures from. 
+	XXX - are there any other such packets than DNS ones?
+    </para>
+	</listitem>
+	<listitem>
+    <para>
+	<command>Resolved DNS names are cached by Wireshark.</command>
+	This is required for acceptable performance.
+	However, if the name resolution information
+	should change while Wireshark is running, 
+	Ethereal won't notice a change to the name resolution information once 
+	it's get cached. If this information changes while Wireshark is running, 
+	e.g. a new DHCP lease takes effect, Ethereal won't notice it.
+	XXX - is this true for all or only for DNS info?
+    </para>
+	</listitem>
+      </itemizedlist>
+    <tip><title>Tip!</title>
+    <para>
+	The name resolution in the packet list is done while the list is filled.
+	If a name could be resolved after a packet was added to the list, that 
+	former entry won't be changed. As the name resolution results are cached, 
+	you can use "View/Reload" to rebuild the packet list, this time with the 
+	correctly resolved names. However, this isn't possible while a capture is
+	in progress.
+    </para>
+    </tip>
+	</section>
+	
+	<section><title>Ethernet name resolution (MAC layer)</title>
+	<para>
+	Try to resolve an Ethernet MAC address (e.g. 00:09:5b:01:02:03) to 
+	something more "human readable".
+	</para>
+    <para><command>ARP name resolution (system service)</command>
+	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>
+	Try to resolve an IP address (e.g. 65.208.228.223) to 
+	something more "human readable".
+	</para>
+    <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. 
+	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.
+	</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>
+	Try to resolve a TCP/UDP port (e.g. 80) to 
+	something more "human readable".
+	</para>
+    <para><command>TCP/UDP port conversion (system service)</command>
+	Ethereal will ask the operating system to convert a TCP or UDP port to 
+	its well known name (e.g. 80 -> http).
+    </para>
+    <para>
+	XXX - mention the role of the /etc/services file 
+	(but don't forget the files and folders section)!
+    </para>
+	</section>
+  </section>
+
+  <section id="ChAdvChecksums"><title>Checksums</title>
+    <para>
+	Several network protocols use checksums to ensure data integrity. 
+    </para>
+	<tip><title>Tip!</title>
+	<para>
+	Applying checksums as described here is also known as 
+	<command>redundancy 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 about checksums 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 offloading</title>
+	<para>
+	The checksum calculation might be done by the network driver, protocol 
+	driver or even in hardware.
+	</para>
+	<para>
+	For example: The Ethernet transmitting hardware calculates the 
+	Ethernet CRC32 checksum and the receiving hardware validates this 
+	checksum. 
+	If the received checksum is wrong 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 (zero or garbage filled) checksum field to the hardware.
+	</para>
+	<note><title>Note!</title>
+	<para>
+	Checksum offloading often causes confusion as the network packets to be 
+	transmitted are handed over to 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>
+	<para>
+	Checksum offloading can be confusing and having a lot of [invalid] 
+	messages on the screen can be quite annoying.
+	As mentioned above, invalid checksums may lead to unreassembled packets,
+	making the analysis of the packet data much harder.
+	</para>
+	<para>
+	You can do two things to avoid this checksum offloading problem:
+      <itemizedlist>
+	<listitem>
+	<para>
+	Turn off the checksum offloading in the network driver, if this option is 
+	available.
+	</para>
+	</listitem>
+	<listitem>
+	<para>
+	Turn off checksum validation of the specific protocol in the Wireshark 
+	preferences.
+	</para>
+	</listitem>
+      </itemizedlist>
+	</para>
+  </section>
+  </section>
+
+</chapter>
+<!-- End of WSUG Chapter Advanced -->
+