path: root/docbook/eug_src/EUG_chapter_advanced.xml

<!-- EUG 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 Ethereal 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 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 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 Ethereal 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 Ethereal'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 Ethereal.</command>
	This is required for acceptable performance.
	However, if the name resolution information
	should change while Ethereal is running, 
	Ethereal won't notice a change to the name resolution information once 
	it's get cached. If this information changes while Ethereal 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 Ethereal 
	preferences.
	</para>
	</listitem>
      </itemizedlist>
	</para>
  </section>
  </section>

</chapter>
<!-- End of EUG Chapter Advanced -->