docbook/eug_src/EUG_chapter_advanced.xml

   1 <!-- EUG Chapter Advanced -->
   2
   3 <!-- $Id: -->
   4
   5 <chapter id="ChapterAdvanced">
   6   <title>Advanced Features</title>
   7
   8   <section id="ChAdvIntroduction"><title>Introduction</title>
   9   <para>
  10   In this chapter some advanced features of Ethereal will be described.
  11   </para>
  12   </section>
  13
  14   <section id="ChAdvFollowTCPSection"><title>Following TCP streams</title>
  15     <para>
  16       There will be occasions when you would like to see the data from a TCP
  17       session in the order that the application layer sees it. Perhaps
  18       you are looking for passwords in a Telnet stream, or you are
  19       trying to make sense of a data stream.  If so, Ethereal's ability to
  20       follow a TCP stream will be useful to you.
  21     </para>
  22     <para>
  23       Simply select a TCP packet in the stream/connection you are interested
  24       in and then select the Follow TCP Stream menu item from the Ethereal
  25       Tools menu.  Ethereal will pop up a separate window with all the data
  26       from the TCP stream laid out in order, as shown in
  27       <xref linkend="ChAdvFollowStream"/>.
  28     </para>
  29         <section><title>The "Follow TCP stream" dialog box </title>
  30     <figure id="ChAdvFollowStream">
  31       <title>The "Follow TCP Stream" dialog box</title>
  32       <graphic entityref="EtherealFollowStream" format="PNG"/>
  33     </figure>
  34     <para>
  35       You can choose from the following actions:
  36       <orderedlist>
  37         <listitem>
  38           <para>
  39             <command>Save As</command> Save the stream data in the currently
  40                 selected format.
  41           </para>
  42         </listitem>
  43         <listitem>
  44           <para>
  45             <command>Print</command> Print the stream data in the currently
  46                 selected format.
  47           </para>
  48         </listitem>
  49         <listitem>
  50           <para>
  51             <command>Direction</command> Choose the stream direction to be
  52                 displayed ("Entire conversation", "data from A to B only" or "data
  53                 from B to A only").
  54           </para>
  55         </listitem>
  56         <listitem>
  57           <para>
  58             <command>Filter out this stream</command> Apply a display filter
  59                 removing the current TCP stream data from the display.
  60           </para>
  61         </listitem>
  62         <listitem>
  63           <para>
  64             <command>Close</command> Close this dialog box.
  65           </para>
  66         </listitem>
  67       </orderedlist>
  68     </para>
  69     <para>
  70       You can then choose to view the data in one of four formats:
  71       <orderedlist>
  72         <listitem>
  73           <para>
  74             <command>ASCII</command>. In this view you see the data from
  75             each end in ASCII, but alternating according to when each
  76             end sent data. Unfortunately, non-printing characters do not
  77             print.
  78           </para>
  79         </listitem>
  80         <listitem>
  81           <para>
  82             <command>EBCDIC</command>. For the big-iron freaks out there.
  83           </para>
  84         </listitem>
  85         <listitem>
  86           <para>
  87             <command>HEX Dump</command>. This allows you to see all the
  88             data, but you lose the ability to read it in ASCII.
  89           </para>
  90         </listitem>
  91         <listitem>
  92           <para>
  93             <command>C Arrays</command>. This allows you to import the stream data
  94                 into your own C program.
  95           </para>
  96         </listitem>
  97       </orderedlist>
  98     </para>
  99     <note>
 100       <title>Note!</title>
 101       <para>
 102         It is worthwhile noting that Follow TCP Stream installs a filter
 103         to select all the packets in the TCP stream you have selected.
 104       </para>
 105     </note>
 106   </section>
 107   </section>
 108
 109   <section id="ChAdvReassemblySection"><title>Packet Reassembling/Desegmenting</title>
 110     <para>
 111         XXX - rework this chapter, as it's still a bit confusing.
 112         </para>
 113     <section><title>What is it?</title>
 114     <para>
 115         Often network protocols needs to transport large chunks of data, which are
 116         complete in itself, e.g. when transferring a file. The underlying
 117         protocol might not be able to handle that chunk size (e.g. limitation of
 118         the network packet size), or is stream-based like TCP, which doesn't know
 119         data chunks at all.
 120     </para>
 121     <para>
 122         In that case the network protocol has to handle that chunks itself and
 123         (if required) spreading the data over multiple packets. It also needs a
 124         mechanism to find back the chunk boundaries on the receiving side.
 125     </para>
 126     <note><title>Reassembling vs. Desegmenting!</title>
 127     <para>
 128         Desegmenting is a slightly different mechanism compared to reassembling,
 129         but doing the same thing. Both mechanisms combine traffic back together,
 130         in this chapter only the term reassembling will be used.
 131         </para>
 132         </note>
 133     </section>
 134     <section><title>How Ethereal handles it</title>
 135     <para>
 136         For some of the network protocols Ethereal knows of, a mechanism is
 137         implemented to find, decode and display this chunks of data.
 138         Ethereal will try to find the corresponding packets of this chunk,
 139         and will show the combined data as additional pages in the
 140         "Packet Bytes" pane, see <xref linkend="ChUsePacketBytesPaneSection"/>.
 141     </para>
 142     <note><title>Note!</title>
 143     <para>
 144         Reassembling might take place in several protocol layers, so it's possible
 145         that multiple tabs in the "Packet Bytes" pane appear.
 146         </para>
 147     </note>
 148     <note><title>Note!</title>
 149     <para>
 150         You will find the reassembled data in the last packet of the chunk.
 151         </para>
 152     </note>
 153     <para>
 154         Some examples:
 155         <itemizedlist>
 156         <listitem>
 157           <para>
 158                 In a <command>HTTP</command> GET response, the requested data (e.g. a
 159                 HTML page) is returned. Ethereal will show the hex dump of the data in
 160                 a new tab "Uncompressed entity body" in the "Packet Bytes" pane.
 161           </para>
 162         </listitem>
 163         <listitem>
 164           <para>
 165                 A <command>DCE-RPC</command> (Remote Procedure Call) client send a
 166                 request to the server and expects a response back from it. Both the
 167                 request and the response is a complete chunk of data and will be
 168                 shown as a new tab "Reassembled DCE/RPC" in the "Packet Bytes" pane.
 169           </para>
 170         </listitem>
 171         </itemizedlist>
 172     </para>
 173     </section>
 174
 175     <section><title>Reassembling is disabled!</title>
 176     <para>
 177         Reassembling is usually disabled in the preferences by default, as it
 178         slows down packet processing a bit.
 179     </para>
 180     <para>
 181         Enabling reassembling of a protocol typically requires two things:
 182         <orderedlist>
 183         <listitem>
 184     <para>
 185         the lower level protocol (e.g., TCP) must support
 186         reassembly. Often this reassembly can be enabled or disabled at will
 187         via the protocol preferences.
 188     </para>
 189         </listitem>
 190         <listitem>
 191     <para>
 192         the higher level protocol (e.g., HTTP) must use the
 193         reassembly mechanism to reassemble fragmented protocol data. This too
 194         can often be enabled or disabled via the protocol preferences.
 195     </para>
 196         </listitem>
 197         </orderedlist>
 198     </para>
 199     <para>
 200         As a result, if reassembly of protocol Y on top of protocol X
 201         must be enabled, it is wise to take a look at the protocol preferences for
 202         both protocols. Check whether protocol X allows subdissectors to
 203         reassemble, and check whether protocol Y supports reassembly
 204         and has it enabled.
 205     </para>
 206     <para>
 207         For example: if you have HTTP on top of TCP, you have to enable the TCP
 208         preference "Allow subdissectors to reassemble" and enable the HTTP
 209         preference "Reassemble".
 210     </para>
 211     </section>
 212   </section>
 213
 214   <section id="ChAdvNameResolutionSection"><title>Name Resolution</title>
 215     <para>
 216         Name resolution tries to resolve some of the address values to human
 217         readable names. This conversion might fail. For example, the name might be
 218         unknown. Some of the lookups are done with data from your local
 219         machine, while others asking network services such as DNS.
 220     </para>
 221     <para>
 222         XXX - add ipxnets name resolution explanation.
 223     </para>
 224     <note><title>Note!</title>
 225     <para>
 226         You might see packets to/from your machine in your capture file, which are
 227         caused by name resolution network services (e.g. DNS packets).
 228     </para>
 229     </note>
 230     <note><title>Note!</title>
 231     <para>
 232         The resolved names are not stored in the capture file or somewhere else,
 233         so the resolved names might not be available if you open the capture file
 234         later or on another machine.
 235     </para>
 236     </note>
 237     <para>
 238         The name resolution feature can be en-/disabled separately for the
 239         following protocol layers:
 240     </para>
 241         <section><title>MAC Layer</title>
 242     <para><command>ARP name resolution</command>
 243         Convert an ethernet address to the corresponding IP address
 244         (e.g. 00:09:5b:01:02:03 -> 192.168.0.1).
 245     </para>
 246     <para><command>Ethernet manufacturer codes</command>
 247         If the ARP name resolution failed, Ethereal tries to convert the first 3
 248         bytes of an ethernet address to an abbreviated manufacturer name, which
 249         has been assigned by the IETF (e.g. 00:09:5b:01:02:03 -> Netgear_01:02:03).
 250     </para>
 251         </section>
 252         <section><title>Network Layer</title>
 253     <para><command>DNS name resolution</command>
 254         Convert an IP address to the hostname associated with it
 255         (e.g. 65.208.228.223 -> www.ethereal.com).
 256     </para>
 257         <warning>
 258           <title>Warning!</title>
 259           <para>
 260                 Enabling network name resolution when your name server is
 261                 unavailable may significantly slow Ethereal while it waits
 262                 for all of the name server requests to time out. Use ADNS in that
 263                 case.
 264           </para>
 265         </warning>
 266         </section>
 267         <section><title>Transport Layer</title>
 268     <para><command>TCP/UDP port conversion</command>
 269         Convert a TCP or UDP port to its well known name (e.g. 80 -> http).
 270     </para>
 271         </section>
 272         <section><title>ADNS</title>
 273         <para>
 274         As noted, DNS lookups can significantly slow down Ethereal and make it
 275         appear frozen, which can be very annoying. To solve this, Ethereal can use
 276         the ADNS library, which handles DNS calls asynchronously.
 277         </para>
 278         </section>
 279   </section>
 280
 281 </chapter>
 282 <!-- End of EUG Chapter Advanced -->
 283