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