Further cleanup of Wireshark User Guide
[obnox/wireshark/wip.git] / docbook / wsug_src / WSUG_chapter_advanced.xml
1 <!-- WSUG Chapter Advanced -->
3 <!-- $Id$ -->
5 <chapter id="ChapterAdvanced">
6   <title>Advanced Topics</title>
8   <section id="ChAdvIntroduction"><title>Introduction</title>
9   <para>
10   In this chapter some of the advanced features of Wireshark will be described.
11   </para>
12   </section>
14   <section id="ChAdvFollowTCPSection"><title>Following TCP streams</title>
15     <para>
16           If you are working with TCP based protocols it can be very helpful
17       to see the data from a TCP stream in the way that the application 
18           layer sees it. 
19           Perhaps you are looking for passwords in a Telnet stream, or you 
20           are trying to make sense of a data stream.
21           Maybe you just need a display filter to show only the packets of that 
22           TCP stream.
23           If so, Wireshark's ability to follow a TCP stream will be useful to you. 
24     </para>
25     <para>
26       Simply select a TCP packet in the packet list of the stream/connection 
27           you are interested in and then select the Follow TCP Stream menu item 
28           from the Wireshark Tools menu (or use the context menu in the packet 
29           list).
30           Wireshark will set an appropriate display filter and pop up a dialog
31           box with all the data from the TCP stream laid out in order, 
32           as shown in <xref linkend="ChAdvFollowStream"/>.
33     </para>
34     <note>
35       <title>Note!</title>
36       <para>
37         It is worthwhile noting that Follow TCP Stream installs a display filter 
38         to select all the packets in the TCP stream you have selected.
39       </para>
40     </note>
41         <section><title>The "Follow TCP Stream" dialog box </title>
42     <figure id="ChAdvFollowStream">
43       <title>The "Follow TCP Stream" dialog box</title>
44       <graphic entityref="WiresharkFollowStream" format="PNG"/>
45     </figure>
46     <para>
47         The stream content is displayed in the same sequence as it appeared on 
48         the network. 
49         Traffic from A to B is marked in red, while traffic from B to A is 
50         marked in blue. 
51         If you like, you can change these colors in the Edit/Preferences 
52         "Colors" page.
53     </para>
54     <para>
55         None printable characters will be replaced by dots.
56         XXX - What about line wrapping (maximum line length) and CRNL conversions?
57     </para>
58     <para>
59         The stream content won't be updated while doing a live capture. 
60         To get the latest content you'll have to reopen the dialog.
61     </para>
62     <para>
63       You can choose from the following actions:
64       <orderedlist>
65         <listitem>
66           <para>
67             <command>Save As</command> Save the stream data in the currently
68                 selected format.
69           </para>
70         </listitem>
71         <listitem>
72           <para>
73             <command>Print</command> Print the stream data in the currently
74                 selected format.
75           </para>
76         </listitem>
77         <listitem>
78           <para>
79             <command>Direction</command> Choose the stream direction to be 
80                 displayed ("Entire conversation", "data from A to B only" or "data 
81                 from B to A only").
82           </para>
83         </listitem>
84         <listitem>
85           <para>
86             <command>Filter out this stream</command> Apply a display filter 
87                 removing the current TCP stream data from the display.
88           </para>
89         </listitem>
90         <listitem>
91           <para>
92             <command>Close</command> Close this dialog box, leaving the current 
93                 display filter in effect.
94           </para>
95         </listitem>
96       </orderedlist>
97     </para>
98     <para>
99       You can choose to view the data in one of the following formats:
100       <orderedlist>
101         <listitem>
102           <para>
103             <command>ASCII</command>. In this view you see the data from 
104             each direction in ASCII. Obviously best for ASCII based protocols, 
105                 e.g. HTTP.
106           </para>
107         </listitem>
108         <listitem>
109           <para>
110             <command>EBCDIC</command>. For the big-iron freaks out there.
111           </para>
112         </listitem>
113         <listitem>
114           <para>
115             <command>HEX Dump</command>. This allows you to see all the 
116             data. 
117                 This will require a lot of screen space and is best used with 
118                 binary protocols.
119           </para>
120         </listitem>
121         <listitem>
122           <para>
123             <command>C Arrays</command>. This allows you to import the stream data
124                 into your own C program.
125           </para>
126         </listitem>
127         <listitem>
128           <para>
129             <command>Raw</command>. This allows you to load the unaltered stream 
130                 data into a different program for further examination. 
131                 The display will look the same as the ASCII setting, but "Save As" 
132                 will result in a binary file.
133           </para>
134         </listitem>
135       </orderedlist>
136     </para>
137   </section>
138   </section>
140   <section id="ChAdvTimestamps"><title>Time Stamps</title>
141         <para>
142         Time stamps, their precisions and all that can be quite 
143         confusing, this section will provide you with information what's going 
144         on while Wireshark processes time stamps.
145         </para>
146     <para>
147         While packets are captured, each packet is time stamped as it comes in.
148         These time stamps will be saved to the capture file, so they also will be 
149         available for (later) analysis. 
150         </para>
151         <para>
152         So where do these time stamps come from?
153         While capturing, Wireshark gets the time stamps from the libpcap (WinPcap) 
154         library, which in turn get's them from the operating system kernel.
155         If the capture data is loaded from a capture file, Wireshark obviously gets 
156         the data from that file.
157         </para>
158   <section><title>Wireshark internals</title>
159         <para>
160         The internal format that Wireshark uses to keep a packet time stamp consists 
161         of the date (in days since 1.1.1970) and the time of day (in nanoseconds 
162         since midnight). You can adjust the way Wireshark displays the time stamp data 
163         in the packet list, see the "Time Display Format" item in the 
164         <xref linkend="ChUseViewMenuSection"/> for details.
165         </para>
166         <para>
167         While reading or writing capture files, Wireshark converts the time stamp 
168         data between the capture file format and the internal format as required.
169         </para>
170         <para>
171         While capturing, Wireshark uses the libpcap (WinPcap) capture library which 
172         supports microsecond resolution. Unless you are working with specialized 
173         capturing hardware, this resolution should be adequate.
174         </para>
175   </section>
176   <section><title>Capture file formats</title>
177         <para>
178         Every capture file format that Wireshark knows support time stamps. 
179         The time stamp precision 
180         supported by a specific capture file format differs widely and varies 
181         from one second "0" to one nanosecond "0.123456789". 
182         Most file formats store the time stamps with a fixed precision 
183         (e.g. microseconds), while some file formats are even capable to store the 
184         time stamp precision itself (whatever the benefit may be).
185         </para>
186         <para>
187         The common libpcap capture file format that is used by Wireshark (and a 
188         lot of other tools) supports a fixed microsecond resolution "0.123456" 
189         only. 
190         </para>
191     <note>
192       <title>Note!</title>
193       <para>
194           Writing data into a capture file format that doesn't provide
195           the capability to store the actual precision will lead to loss of information.
196           Example: If you load a capture file with nanosecond resolution and 
197           store the capture data to a libpcap file (with microsecond resolution)
198           Wireshark obviously must reduce the precision from nanosecond to microsecond.
199       </para>
200     </note>
201   </section>
202   <section><title>Accuracy</title>
203         <para>
204         It's often asked: "Which time stamp accuracy is provided by Wireshark?". 
205         Well, Wireshark doesn't create any time stamps itself but simply get's them
206         from "somewhere else" and displays them. So accuracy will depend on the 
207         capture system (operating system, performance, ...) that you use. 
208         Because of this, the above question is difficult to answer in a 
209         general way.
210     <note>
211       <title>Note!</title>
212       <para>
213           USB connected network adapters often provide a very bad time stamp 
214           accuracy. The incoming packets have to take "a long and winding 
215           road" to travel through the USB cable until they actually reach the 
216           kernel. As the incoming packets are time stamped when they are processed 
217           by the kernel, this time stamping mechanism becomes very inaccurate.
218       </para>
219       <para>
220           Conclusion: don't use USB connected NIC's when you need precise
221           time stamp accuracy! (XXX - are there any such NIC's that stamps already 
222           on the USB hardware?)
223       </para>
224     </note>
225         </para>
226   </section>
227   </section>
229   <section id="ChAdvTimezones"><title>Time Zones</title>
230         <para>
231         If you travel across the planet, time zones can be confusing. If you get a 
232         capture file from somewhere around the world time zones can even be a lot 
233         more confusing ;-) 
234         </para>
235         <para>
236         First of all, there are two reasons why you may not need to think about 
237         time zones at all:
238         <itemizedlist>
239           <listitem>
240           <para>
241                 You are only interested in the time differences between the packet 
242                 time stamps and don't need to know the exact date and time of the 
243                 captured packets (which is often the case).
244           </para>
245           </listitem>
246           <listitem>
247           <para>
248                 You don't get capture files from different time zones than your own, 
249                 so there are simply no time zone problems. For example: everyone in 
250                 your team is working in the same time zone than yourself.
251           </para>
252           </listitem>
253         </itemizedlist>
254         </para>
255         <sidebar><title>What are time zones?</title>
256         <para>
257         People expect that the time reflects the sunset. Dawn should be in the 
258         morning maybe around 06:00 and dusk in the evening maybe at 20:00.
259         These times will obviously vary depending on the season. 
260         It would be very confusing if everyone on earth would use the same 
261         global time as this would correspond to the sunset only at a small part 
262         of the world. 
263         </para>
264         <para>
265         For that reason, the earth is split into several different time zones, 
266         each zone with a local time that corresponds to the local sunset.
267         </para>
268         <para>
269         The time zone's base time is UTC (Coordinated Universal Time) or Zulu 
270         Time (military and aviation). The older term GMT (Greenwich Mean Time) 
271         shouldn't be used as it is slightly incorrect (up to 0.9 seconds 
272         difference to UTC). 
273         The UTC base time equals to 0 (based at Greenwich, England) and all 
274         time zones have an offset to UTC between -12 to +14 hours!
275         </para>
276         <para>
277         For example: If you live in 
278         Berlin you are in a time zone one hour earlier than UTC, so you are in 
279         time zone "+1" (time difference in hours compared to UTC). If it's 
280         3 o'clock in Berlin it's 2 o'clock in UTC "at the same moment".
281         </para>
282         <para>
283         Be aware that at a few places on earth don't use time zones with even 
284         hour offsets (e.g. New Delhi uses UTC+05:30)!
285         </para>
286         <para>
287         Further information can be found at: 
288         <ulink url="&WikipediaTimezone;">&WikipediaTimezone;</ulink> and 
289         <ulink url="&WikipediaUTC;">&WikipediaUTC;</ulink>.
290         </para>
292         </sidebar>
293         <sidebar><title>What is daylight saving time (DST)?</title>
294         <para>
295         Daylight Saving Time (DST), also known as Summer Time, is intended to 
296         "save" some daylight during the summer months. 
297         To do this, a lot of countries (but not all!) add an DST hour to the 
298         already existing UTC offset. 
299         So you may need to take another hour (or in very rare cases even two 
300         hours!) difference into your "time zone calculations". 
301         </para>
302         <para>
303         Unfortunately, the date at which DST actually takes effect is different 
304         throughout the world. You may also note, that the northern and southern 
305         hemispheres have opposite DST's (e.g. while it's summer in Europe it's 
306         winter in Australia). 
307         </para>
308         <para>
309         Keep in mind: UTC remains the same all year around, regardless of DST!
310         </para>
311         <para>
312         Further information can be found at: 
313         <ulink url="&WikipediaDaylightSaving;">&WikipediaDaylightSaving;</ulink>.
314         </para>
315         </sidebar>
316         <para>  
317         Further time zone and DST information can be found at: 
318         <ulink url="&TimezoneGMTSite;">&TimezoneGMTSite;</ulink> and
319         <ulink url="&TimezoneWorldClockSite;">&TimezoneWorldClockSite;</ulink>.
320         </para>
321   <section><title>Set your computer's time correct!</title>
322         <para>
323         If you work with people around the world, it's very helpful to set your 
324         computer's time and time zone right.
325         </para>
326         <para>
327         You should set your computers time and time zone in the correct sequence:
328         <orderedlist>
329           <listitem>
330           <para>
331                 Set your time zone to your current location
332           </para>
333           </listitem>
334           <listitem>
335           <para>
336                 Set your computer's clock to the local time
337           </para>
338           </listitem>
339         </orderedlist>
340         This way you will tell your computer both the local time and also the time 
341         offset to UTC.
342         <tip><title>Tip!</title>
343         <para>
344         If you travel around the world, it's an often made mistake to adjust the 
345         hours of your computer clock to the local time. Don't adjust the 
346         hours but your time zone setting instead! For your computer, the time is 
347         essentially the same as before, you are simply in a different time zone 
348         with a different local time!
349         </para>
350         </tip>
351         <tip><title>Tip!</title>
352         <para>
353         You can use the Network Time Protocol (NTP) to automatically adjust your 
354         computer to the correct time, by synchronizing it to internet NTP clock 
355         servers. NTP clients are available for all operating systems that 
356         Wireshark supports (and for a lot more), for examples see:
357         <ulink url="&NTPSite;">&NTPSite;</ulink>.
358         </para>
359         </tip>
360         </para>
361   </section>
362   <section><title>Wireshark and Time Zones</title>
363         <para>
364         So what's the relationship between Wireshark and time zones anyway? 
365         </para>
366         <para>
367         Wireshark's native capture file format (libpcap format), and some
368         other capture file formats, such as the Windows Sniffer,
369         EtherPeek, AiroPeek, and Sun snoop formats, save the arrival
370         time of packets as UTC values.  
371         UN*X systems, and "Windows NT based" systems (Windows NT 4.0, 
372         Windows 2000, Windows XP, Windows Server 2003, Windows Vista) 
373         represent time internally as UTC.
374         When Wireshark is capturing, no conversion is necessary.
375         However, if the system time zone is not set
376         correctly, the system's UTC time might not be correctly set even
377         if the system clock appears to display correct local time. 
378         "Windows 9x based" systems (Windows 95, Windows 98, Windows Me)
379         represent time internally as local time. 
380         When capturing, WinPcap has to convert the time to UTC before 
381         supplying it to Wireshark. 
382         If the system's time zone is not set correctly, that conversion will 
383         not be done correctly.
384         </para>
385         <para>
386         Other capture file formats, such as the Microsoft Network
387         Monitor, DOS-based Sniffer, and Network Instruments Observer
388         formats, save the arrival time of packets as local time values.
389         </para>
390         <para>
391         Internally to Wireshark, time stamps are represented in UTC; this
392         means that, when reading capture files that save the arrival
393         time of packets as local time values, Wireshark must convert
394         those local time values to UTC values.
395         </para>
396         <para>
397         Wireshark in turn will display the time stamps always in local
398         time.  The displaying computer will convert them from UTC to
399         local time and displays this (local) time.  For capture files
400         saving the arrival time of packets as UTC values, this means
401         that the arrival time will be displayed as the local time in
402         your time zone, which might not be the same as the arrival time
403         in the time zone in which the packet was captured.  For capture
404         files saving the arrival time of packets as local time values,
405         the conversion to UTC will be done using your time zone's offset
406         from UTC and DST rules, which means the conversion will not be
407         done correctly; the conversion back to local time for display
408         might undo this correctly, in which case the arrival time will
409         be displayed as the arrival time in which the packet was
410         captured.
411         </para>
412         <para>
413     <table id="ChAdvTabTimezones" frame="none">
414       <title>Time zone examples for UTC arrival times (without DST)</title>
415       <tgroup cols="7">
416 <!--    <colspec colnum="1" colwidth="72pt"/>
417           <colspec colnum="2" colwidth="80pt"/>
418           <colspec colnum="3" colwidth="80pt"/>-->
419             <thead>
420               <row>
421                 <entry></entry>
422                 <entry>Los Angeles</entry>
423                 <entry>New York</entry>
424                 <entry>Madrid</entry>
425                 <entry>London</entry>
426                 <entry>Berlin</entry>
427                 <entry>Tokyo</entry>
428               </row>
429             </thead>
430             <tbody>
431               <row>
432                 <entry><command>Capture File (UTC)</command></entry>
433                 <entry>10:00</entry>
434                 <entry>10:00</entry>
435                 <entry>10:00</entry>
436                 <entry>10:00</entry>
437                 <entry>10:00</entry>
438                 <entry>10:00</entry>
439               </row>
440               <row>
441                 <entry><command>Local Offset to UTC</command></entry>
442                 <entry>-8</entry>
443                 <entry>-5</entry>
444                 <entry>-1</entry>
445                 <entry>0</entry>
446                 <entry>+1</entry>
447                 <entry>+9</entry>
448               </row>
449               <row>
450                 <entry><command>Displayed Time (Local Time)</command></entry>
451                 <entry>02:00</entry>
452                 <entry>05:00</entry>
453                 <entry>09:00</entry>
454                 <entry>10:00</entry>
455                 <entry>11:00</entry>
456                 <entry>19:00</entry>
457               </row>
458             </tbody>
459       </tgroup>
460     </table>
461         </para>
462         <para>
463         An example:
464         Let's assume that someone in Los Angeles captured a packet with
465         Wireshark at exactly 2 o'clock local time and sents you this
466         capture file.  The capture file's time stamp will be represented
467         in UTC as 10 o'clock.  You are located in Berlin and will see 11
468         o'clock on your Wireshark display.
469         </para>
470         <para>
471         Now you have a phone call, video conference or internet meeting with that 
472         one to talk about that capture file. 
473         As you are both looking at the displayed time on your local computers, 
474         the one in Los Angeles still sees 2 o'clock but you in Berlin will see 
475         11 o'clock. The time displays are different as both Wireshark displays 
476         will show the (different) local times at the same point in time.
477         </para>
478         <para>
479         <command>Conclusion</command>: You may not bother about the date/time 
480         of the time stamp you currently look at, unless you must make sure that 
481         the date/time is as expected. 
482         So, if you get a capture file from a different time zone and/or DST, you'll
483         have to find out the time zone/DST difference between the two local times 
484         and "mentally adjust" the time stamps accordingly.
485         In any case, make sure that every computer in question has the correct 
486         time and time zone setting.
487         </para>
488   </section>
489   </section>
491   <section id="ChAdvReassemblySection"><title>Packet Reassembling</title>
492     <section><title>What is it?</title>
493     <para>
494         Network protocols often need to transport large chunks of data, which are 
495         complete in itself, e.g. when transferring a file. The underlying 
496         protocol might not be able to handle that chunk size (e.g. limitation of 
497         the network packet size), or is stream-based like TCP, which doesn't know 
498         data chunks at all.
499     </para>
500     <para>
501         In that case the network protocol has to handle that chunk boundaries 
502         itself and (if required) spreading the data over multiple packets. 
503         It obviously also needs a mechanism to find back the chunk boundaries on 
504         the receiving side.
505     </para>
506         <tip><title>Tip!</title>
507     <para>
508         Wireshark calls this mechanism reassembling, although a specific protocol  
509         specification might use a different term for this (e.g. desegmentation, 
510         defragmentation, ...).
511         </para>
512         </tip>
513     </section>
514     <section><title>How Wireshark handles it</title>
515     <para>
516         For some of the network protocols Wireshark knows of, a mechanism is 
517         implemented to find, decode and display these chunks of data. 
518         Wireshark will try to find the corresponding packets of this chunk, 
519         and will show the combined data as additional pages in the 
520         "Packet Bytes" pane
521         (for information about this pane, see <xref 
522         linkend="ChUsePacketBytesPaneSection"/>).
523     </para>
524     <para>
525     <figure id="ChAdvWiresharkBytesPaneTabs">
526       <title>The "Packet Bytes" pane with a reassembled tab</title>
527       <graphic entityref="WiresharkBytesPaneTabs" format="PNG"/>
528     </figure>
529     </para>
531     <note><title>Note!</title>
532     <para>
533         Reassembling might take place at several protocol layers, so it's possible 
534         that multiple tabs in the "Packet Bytes" pane appear.
535         </para>
536     </note>
537     <note><title>Note!</title>
538     <para>
539         You will find the reassembled data in the last packet of the chunk.
540         </para>
541     </note>
542     <para>
543         An example:
544                 In a <command>HTTP</command> GET response, the requested data (e.g. a 
545                 HTML page) is returned. Wireshark will show the hex dump of the data in 
546                 a new tab "Uncompressed entity body" in the "Packet Bytes" pane.
547     </para>
548     <para>
549         Reassembling is enabled in the preferences by default. The defaults 
550         were changed from disabled to enabled in September 2005. If you created 
551         your preference settings before this date, you might look if reassembling 
552         is actually enabled, as it can be extremely helpful while analyzing 
553         network packets.
554     </para>
555     <para>
556         The enabling or disabling of the reassemble settings of a protocol typically 
557         requires two things:
558         <orderedlist>
559         <listitem>
560     <para>
561         the lower level protocol (e.g., TCP) must support
562         reassembly. Often this reassembly can be enabled or disabled 
563         via the protocol preferences.
564     </para>
565         </listitem>
566         <listitem>
567     <para>
568         the higher level protocol (e.g., HTTP) must use the
569         reassembly mechanism to reassemble fragmented protocol data. This too
570         can often be enabled or disabled via the protocol preferences.
571     </para>
572         </listitem>
573         </orderedlist>
574     </para>
575     <para>
576         The tooltip of the higher level protocol setting will note you if and 
577         which lower level protocol setting has to be considered too.
578     </para>
579     </section>
580   </section>
582   <section id="ChAdvNameResolutionSection"><title>Name Resolution</title>
583     <para>
584         Name resolution tries to resolve some of the numerical address values into 
585         a human readable format. There are two possible ways to do this 
586         conversations, depending on the resolution to be done: calling 
587         system/network services (like the gethostname function) and/or evaluate 
588         from Wireshark specific configuration files. 
589         For details about the configuration files Wireshark uses for name 
590         resolution and alike, see <xref linkend="AppFiles"/>.
591         </para>
592     <para>
593         The name resolution feature can be en-/disabled separately for the 
594         protocol layers of the following sections.
595     </para>
597         <section><title>Name Resolution drawbacks</title>
598     <para>
599         Name resolution can be invaluable while working with Wireshark and may 
600         save you even hours of work. Unfortunately, it also has it's drawbacks.
601     </para>
602       <itemizedlist>
603         <listitem>
604         <para>
605         <command>Name resolution will often fail.</command> The name to be 
606         resolved might simply be unknown by the name servers asked or the servers 
607         are just not available and the name is also not found in Wireshark's 
608         configuration files.
609     </para>
610         </listitem>
611         <listitem>
612     <para>
613         <command>The resolved names are not stored in the capture file or 
614         somewhere else.</command>
615         So the resolved names might not be available if you open the capture file
616         later or on a different machine.
617         Each time you open a capture file it may look "slightly different", 
618         maybe simply because you can't connect a name server (which you could 
619         connect before).
620     </para>
621         </listitem>
622         <listitem>
623     <para>
624         <command>DNS may add additional packets to your capture file.</command>
625         You may see packets to/from your machine in your capture file, which are
626         caused by name resolution network services of the machine Wireshark 
627         captures from. 
628         XXX - are there any other such packets than DNS ones?
629     </para>
630         </listitem>
631         <listitem>
632     <para>
633         <command>Resolved DNS names are cached by Wireshark.</command>
634         This is required for acceptable performance.
635         However, if the name resolution information
636         should change while Wireshark is running, 
637         Wireshark won't notice a change to the name resolution information once 
638         it's get cached. If this information changes while Wireshark is running, 
639         e.g. a new DHCP lease takes effect, Wireshark won't notice it.
640         XXX - is this true for all or only for DNS info?
641     </para>
642         </listitem>
643       </itemizedlist>
644     <tip><title>Tip!</title>
645     <para>
646         The name resolution in the packet list is done while the list is filled.
647         If a name could be resolved after a packet was added to the list, that 
648         former entry won't be changed. As the name resolution results are cached, 
649         you can use "View/Reload" to rebuild the packet list, this time with the 
650         correctly resolved names. However, this isn't possible while a capture is
651         in progress.
652     </para>
653     </tip>
654         </section>
656         <section><title>Ethernet name resolution (MAC layer)</title>
657         <para>
658         Try to resolve an Ethernet MAC address (e.g. 00:09:5b:01:02:03) to 
659         something more "human readable".
660         </para>
661     <para><command>ARP name resolution (system service)</command>
662         Wireshark will ask the operating system to convert an ethernet address 
663         to the corresponding IP address (e.g. 00:09:5b:01:02:03 -> 
664     </para>
665     <para><command>Ethernet codes (ethers file)</command>
666         If the ARP name resolution failed, Wireshark tries to convert the ethernet 
667         address to a known device name, which has been assigned by the user using 
668         an ethers file (e.g. 00:09:5b:01:02:03 -> homerouter).
669     </para>
670     <para><command>Ethernet manufacturer codes (manuf file)</command>
671         If both ARP and ethers didn't returned a result, Wireshark tries to convert 
672         the first 3 bytes of an ethernet address to an abbreviated manufacturer name, 
673         which has been assigned by the IEC 
674         (e.g. 00:09:5b:01:02:03 -> Netgear_01:02:03).
675     </para>
676         </section>
678         <section><title>IP name resolution (network layer)</title>
679         <para>
680         Try to resolve an IP address (e.g. to 
681         something more "human readable".
682         </para>
683     <para><command>DNS/ADNS name resolution (system/library service)</command>
684         Wireshark will ask the operating system (or the ADNS library), 
685         to convert an IP address to the hostname associated with it 
686         (e.g. -> www.1.google.com). The DNS service is using 
687         synchronous calls to the DNS server. So Wireshark will stop responding 
688         until a response to a DNS request is returned. If possible, you might 
689         consider using the ADNS library (which won't wait for a network response).
690     </para>
691         <warning>
692           <title>Warning!</title>
693           <para>
694                 Enabling network name resolution when your name server is 
695                 unavailable may significantly slow down Wireshark while it waits 
696                 for all of the name server requests to time out. Use ADNS in that 
697                 case.
698           </para>
699         </warning>      
700         <para>
701         <command>DNS vs. ADNS</command>
702         here's a short comparison: Both mechanisms are 
703         used to convert an IP address to some human readable (domain) name. The 
704         usual DNS call gethostname() will try to convert the address to a name. 
705         To do this, it will first ask the systems hosts file (e.g. /etc/hosts) 
706         if it finds a matching entry. If that fails, it will ask the configured 
707         DNS server(s) about the name.
708         </para>
709         <para>
710         So the real difference between DNS and ADNS comes when the system has 
711         to wait for the DNS server about a name resolution. 
712         The system call gethostname() will wait until a name is resolved or an 
713         error occurs. 
714         If the DNS server is unavailable, this might take quite 
715         a while (several seconds).
716         The ADNS service will work a bit differently.
717         It will also ask the DNS server, but it won't wait for the answer. 
718         It will just return to Wireshark in a very short amount of time. 
719         The actual (and the following) address fields won't show the resolved 
720         name until the ADNS call returned. As mentioned above, the values get 
721         cached, so you can use View/Reload to "update" these fields to show the 
722         resolved values.
723         </para>
724     <para><command>hosts name resolution (hosts file)</command>
725         If DNS name resolution failed, Wireshark will try to convert an IP address 
726         to the hostname associated with it, using a hosts file provided by the 
727         user (e.g. -> www.google.com).
728     </para>
729         </section>
731         <section><title>IPX name resolution (network layer)</title>
732     <para><command>ipxnet name resolution (ipxnets file)</command>
733         XXX - add ipxnets name resolution explanation.
734     </para>
735         </section>
737         <section><title>TCP/UDP port name resolution (transport layer)</title>
738         <para>
739         Try to resolve a TCP/UDP port (e.g. 80) to 
740         something more "human readable".
741         </para>
742     <para><command>TCP/UDP port conversion (system service)</command>
743         Wireshark will ask the operating system to convert a TCP or UDP port to 
744         its well known name (e.g. 80 -> http).
745     </para>
746     <para>
747         XXX - mention the role of the /etc/services file 
748         (but don't forget the files and folders section)!
749     </para>
750         </section>
751   </section>
753   <section id="ChAdvChecksums"><title>Checksums</title>
754     <para>
755         Several network protocols use checksums to ensure data integrity. 
756     </para>
757         <tip><title>Tip!</title>
758         <para>
759         Applying checksums as described here is also known as 
760         <command>redundancy check</command>.
761         </para>
762         </tip>
763         <sidebar><title>What are checksums for?</title>
764         <para>
765         Checksums are used to ensure the integrity of data portions for data 
766         transmission or storage.
767         A checksum is basically a calculated summary of such a data portion. 
768         </para>
769         <para>
770         Network data transmissions often produce errors, such as toggled, missing 
771         or duplicated bits. 
772         As a result, the data received might not be identical to the data 
773         transmitted, which is obviously a bad thing.
774         </para>
775         <para>
776         Because of these transmission errors, network protocols very often use 
777         checksums to detect such errors.
778         The transmitter will calculate a checksum of the data and transmits the 
779         data together with the checksum.
780         The receiver will calculate the checksum of the received data with the same
781         algorithm as the transmitter.
782         If the received and calculated checksums don't match a transmission error
783         has occured.
784         </para>
785         <para>
786         Some checksum algorithms are able to recover (simple) errors by 
787         calculating where the expected error must be and repairing it. 
788         </para>
789         <para>
790         If there are errors that cannot be recovered, the receiving side throws 
791         away the packet. Depending on the network protocol, this data loss is 
792         simply ignored or the sending side needs to detect this loss somehow and 
793         retransmits the required packet(s).
794         </para>
795         <para>
796         Using a checksum drastically reduces the number of undetected transmission 
797         errors. However, the usual checksum algorithms cannot guarantee an error 
798         detection of 100%, so a very small number of transmission errors may 
799         remain undetected.
800         </para>
801         <para>
802         There are several different kinds of checksum algorithms, an example of 
803         an often used checksum algorithm is CRC32. 
804         The checksum algorithm actually chosen for a specific network protocol 
805         will depend on the expected error rate of the network medium, the 
806         importance of error detection, the processor load to perform the 
807         calculation, the performance needed and many other things.
808         </para>
809         <para>
810         Further information about checksums can be found at:
811         <ulink url="&WikipediaWebsite;/wiki/Checksum"/>.
812         </para>
813         </sidebar>
814   <section><title>Wireshark checksum validation</title>
815         <para>
816         Wireshark will validate the checksums of several potocols, e.g.: IP, TCP, ...
817         </para>
818         <para>
819         It will do the same calculation as a "normal receiver" would do, 
820         and shows the checksum fields in the packet details with a comment, e.g.:
821         [correct], [invalid, must be 0x12345678] or alike.
822         </para>
823         <para>
824         Checksum validation can be switched off for various protocols in the 
825         Wireshark protocol preferences, e.g. to (very slightly) increase 
826         performance.
827         </para>
828         <para>
829         If the checksum validation is enabled and it detected an invalid checksum,
830         features like packet reassembling won't be processed. 
831         This is avoided as incorrect connection data could "confuse" the internal 
832         database.
833         </para>
834   </section>
836   <section><title>Checksum offloading</title>
837         <para>
838         The checksum calculation might be done by the network driver, protocol 
839         driver or even in hardware.
840         </para>
841         <para>
842         For example: The Ethernet transmitting hardware calculates the 
843         Ethernet CRC32 checksum and the receiving hardware validates this 
844         checksum. 
845         If the received checksum is wrong Wireshark won't even see the packet, 
846         as the Ethernet hardware internally throws away the packet.
847         </para>
848         <para>
849         Higher level checksums are "traditionally" calculated by the protocol 
850         implementation and the completed packet is then handed over to the 
851         hardware.
852         </para>
853         <para>
854         Recent network hardware can perform advanced features such as IP checksum 
855         calculation, also known as checksum offloading.
856         The network driver won't calculate the checksum itself but simply hand 
857         over an empty (zero or garbage filled) checksum field to the hardware.
858         </para>
859         <note><title>Note!</title>
860         <para>
861         Checksum offloading often causes confusion as the network packets to be 
862         transmitted are handed over to Wireshark before the checksums are actually 
863         calculated.
864         Wireshark gets these "empty" checksums and displays them as 
865         invalid, even though the packets will contain valid checksums when they 
866         leave the network hardware later.
867         </para>
868         </note>
869         <para>
870         Checksum offloading can be confusing and having a lot of [invalid] 
871         messages on the screen can be quite annoying.
872         As mentioned above, invalid checksums may lead to unreassembled packets,
873         making the analysis of the packet data much harder.
874         </para>
875         <para>
876         You can do two things to avoid this checksum offloading problem:
877       <itemizedlist>
878         <listitem>
879         <para>
880         Turn off the checksum offloading in the network driver, if this option is 
881         available.
882         </para>
883         </listitem>
884         <listitem>
885         <para>
886         Turn off checksum validation of the specific protocol in the Wireshark 
887         preferences.
888         </para>
889         </listitem>
890       </itemizedlist>
891         </para>
892   </section>
893   </section>
895 </chapter>
896 <!-- End of WSUG Chapter Advanced -->