1 <!-- WSUG Chapter Advanced -->
5 <chapter id="ChapterAdvanced">
6 <title>Advanced Topics</title>
8 <section id="ChAdvIntroduction"><title>Introduction</title>
10 In this chapter some of the advanced features of Ethereal will be described.
14 <section id="ChAdvFollowTCPSection"><title>Following TCP streams</title>
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
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
23 If so, Ethereal's ability to follow a TCP stream will be useful to you.
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
30 Ethereal 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"/>.
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.
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="EtherealFollowStream" format="PNG"/>
47 The stream content is displayed in the same sequence as it appeared on
49 Traffic from A to B is marked in red, while traffic from B to A is
51 If you like, you can change these colors in the Edit/Preferences
55 None printable characters will be replaced by dots.
56 XXX - What about line wrapping (maximum line length) and CRNL conversions?
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.
63 You can choose from the following actions:
67 <command>Save As</command> Save the stream data in the currently
73 <command>Print</command> Print the stream data in the currently
79 <command>Direction</command> Choose the stream direction to be
80 displayed ("Entire conversation", "data from A to B only" or "data
86 <command>Filter out this stream</command> Apply a display filter
87 removing the current TCP stream data from the display.
92 <command>Close</command> Close this dialog box, leaving the current
93 display filter in effect.
99 You can choose to view the data in one of the following formats:
103 <command>ASCII</command>. In this view you see the data from
104 each direction in ASCII. Obviously best for ASCII based protocols,
110 <command>EBCDIC</command>. For the big-iron freaks out there.
115 <command>HEX Dump</command>. This allows you to see all the
117 This will require a lot of screen space and is best used with
123 <command>C Arrays</command>. This allows you to import the stream data
124 into your own C program.
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.
140 <section id="ChAdvTimestamps"><title>Time Stamps</title>
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 Ethereal processes time stamps.
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.
152 So where do these time stamps come from?
153 While capturing, Ethereal 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, Ethereal obviously gets
156 the data from that file.
158 <section><title>Ethereal internals</title>
160 The internal format that Ethereal 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 Ethereal displays the time stamp data
163 in the packet list, see the "Time Display Format" item in the
164 <xref linkend="ChUseViewMenuSection"/> for details.
167 While reading or writing capture files, Ethereal converts the time stamp
168 data between the capture file format and the internal format as required.
171 While capturing, Ethereal 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.
176 <section><title>Capture file formats</title>
178 Every capture file format that Ethereal 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).
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"
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 Ethereal obviously must reduce the precision from nanosecond to microsecond.
202 <section><title>Accuracy</title>
204 It's often asked: "Which time stamp accuracy is provided by Wireshark?".
205 Well, Ethereal 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
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.
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?)
229 <section id="ChAdvTimezones"><title>Time Zones</title>
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
236 First of all, there are two reasons why you may not need to think about
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).
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.
255 <sidebar><title>What are time zones?</title>
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
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.
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
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!
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".
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)!
287 Further information can be found at:
288 <ulink url="&WikipediaTimezone;">&WikipediaTimezone;</ulink> and
289 <ulink url="&WikipediaUTC;">&WikipediaUTC;</ulink>.
293 <sidebar><title>What is daylight saving time (DST)?</title>
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".
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).
309 Keep in mind: UTC remains the same all year around, regardless of DST!
312 Further information can be found at:
313 <ulink url="&WikipediaDaylightSaving;">&WikipediaDaylightSaving;</ulink>.
317 Further time zone and DST information can be found at:
318 <ulink url="&TimezoneGMTSite;">&TimezoneGMTSite;</ulink> and
319 <ulink url="&TimezoneWorldClockSite;">&TimezoneWorldClockSite;</ulink>.
321 <section><title>Set your computer's time correct!</title>
323 If you work with people around the world, it's very helpful to set your
324 computer's time and time zone right.
327 You should set your computers time and time zone in the correct sequence:
331 Set your time zone to your current location
336 Set your computer's clock to the local time
340 This way you will tell your computer both the local time and also the time
342 <tip><title>Tip!</title>
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!
351 <tip><title>Tip!</title>
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 Ethereal supports (and for a lot more), for examples see:
357 <ulink url="&NTPSite;">&NTPSite;</ulink>.
362 <section><title>Ethereal and Time Zones</title>
364 So what's the relationship between Ethereal and time zones anyway?
367 Ethereal'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 Ethereal.
382 If the system's time zone is not set correctly, that conversion will
383 not be done correctly.
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.
391 Internally to Ethereal, 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, Ethereal must convert
394 those local time values to UTC values.
397 Ethereal 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
413 <table id="ChAdvTabTimezones" frame="none">
414 <title>Time zone examples for UTC arrival times (without DST)</title>
416 <!-- <colspec colnum="1" colwidth="72pt"/>
417 <colspec colnum="2" colwidth="80pt"/>
418 <colspec colnum="3" colwidth="80pt"/>-->
422 <entry>Los Angeles</entry>
423 <entry>New York</entry>
424 <entry>Madrid</entry>
425 <entry>London</entry>
426 <entry>Berlin</entry>
432 <entry><command>Capture File (UTC)</command></entry>
441 <entry><command>Local Offset to UTC</command></entry>
450 <entry><command>Displayed Time (Local Time)</command></entry>
464 Let's assume that someone in Los Angeles captured a packet with
465 Ethereal 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 Ethereal display.
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 Ethereal displays
476 will show the (different) local times at the same point in time.
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.
491 <section id="ChAdvReassemblySection"><title>Packet Reassembling</title>
492 <section><title>What is it?</title>
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
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
506 <tip><title>Tip!</title>
508 Ethereal calls this mechanism reassembling, although a specific protocol
509 specification might use a different term for this (e.g. desegmentation,
510 defragmentation, ...).
514 <section><title>How Ethereal handles it</title>
516 For some of the network protocols Ethereal knows of, a mechanism is
517 implemented to find, decode and display these chunks of data.
518 Ethereal will try to find the corresponding packets of this chunk,
519 and will show the combined data as additional pages in the
521 (for information about this pane, see <xref
522 linkend="ChUsePacketBytesPaneSection"/>).
525 <figure id="ChAdvEtherealBytesPaneTabs">
526 <title>The "Packet Bytes" pane with a reassembled tab</title>
527 <graphic entityref="EtherealBytesPaneTabs" format="PNG"/>
531 <note><title>Note!</title>
533 Reassembling might take place at several protocol layers, so it's possible
534 that multiple tabs in the "Packet Bytes" pane appear.
537 <note><title>Note!</title>
539 You will find the reassembled data in the last packet of the chunk.
544 In a <command>HTTP</command> GET response, the requested data (e.g. a
545 HTML page) is returned. Ethereal will show the hex dump of the data in
546 a new tab "Uncompressed entity body" in the "Packet Bytes" pane.
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
556 The enabling or disabling of the reassemble settings of a protocol typically
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.
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.
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.
582 <section id="ChAdvNameResolutionSection"><title>Name Resolution</title>
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 Ethereal specific configuration files.
589 For details about the configuration files Ethereal uses for name
590 resolution and alike, see <xref linkend="AppFiles"/>.
593 The name resolution feature can be en-/disabled separately for the
594 protocol layers of the following sections.
597 <section><title>Name Resolution drawbacks</title>
599 Name resolution can be invaluable while working with Ethereal and may
600 save you even hours of work. Unfortunately, it also has it's drawbacks.
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
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
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 Ethereal
628 XXX - are there any other such packets than DNS ones?
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 Ethereal 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, Ethereal won't notice it.
640 XXX - is this true for all or only for DNS info?
644 <tip><title>Tip!</title>
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
656 <section><title>Ethernet name resolution (MAC layer)</title>
658 Try to resolve an Ethernet MAC address (e.g. 00:09:5b:01:02:03) to
659 something more "human readable".
661 <para><command>ARP name resolution (system service)</command>
662 Ethereal will ask the operating system to convert an ethernet address
663 to the corresponding IP address (e.g. 00:09:5b:01:02:03 -> 192.168.0.1).
665 <para><command>Ethernet codes (ethers file)</command>
666 If the ARP name resolution failed, Ethereal 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).
670 <para><command>Ethernet manufacturer codes (manuf file)</command>
671 If both ARP and ethers didn't returned a result, Ethereal 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).
678 <section><title>IP name resolution (network layer)</title>
680 Try to resolve an IP address (e.g. 65.208.228.223) to
681 something more "human readable".
683 <para><command>DNS/ADNS name resolution (system/library service)</command>
684 Ethereal will ask the operating system (or the ADNS library),
685 to convert an IP address to the hostname associated with it
686 (e.g. 65.208.228.223 -> www.ethereal.com). The DNS service is using
687 synchronous calls to the DNS server. So Ethereal 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).
692 <title>Warning!</title>
694 Enabling network name resolution when your name server is
695 unavailable may significantly slow down Ethereal while it waits
696 for all of the name server requests to time out. Use ADNS in that
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.
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
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 Ethereal 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
724 <para><command>hosts name resolution (hosts file)</command>
725 If DNS name resolution failed, Ethereal will try to convert an IP address
726 to the hostname associated with it, using an hosts file provided by the
727 user (e.g. 65.208.228.223 -> www.ethereal.com).
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.
737 <section><title>TCP/UDP port name resolution (transport layer)</title>
739 Try to resolve a TCP/UDP port (e.g. 80) to
740 something more "human readable".
742 <para><command>TCP/UDP port conversion (system service)</command>
743 Ethereal will ask the operating system to convert a TCP or UDP port to
744 its well known name (e.g. 80 -> http).
747 XXX - mention the role of the /etc/services file
748 (but don't forget the files and folders section)!
753 <section id="ChAdvChecksums"><title>Checksums</title>
755 Several network protocols use checksums to ensure data integrity.
757 <tip><title>Tip!</title>
759 Applying checksums as described here is also known as
760 <command>redundancy check</command>.
763 <sidebar><title>What are checksums for?</title>
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.
770 Network data transmissions often produce errors, such as toggled, missing
772 As a result, the data received might not be identical to the data
773 transmitted, which is obviously a bad thing.
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
786 Some checksum algorithms are able to recover (simple) errors by
787 calculating where the expected error must be and repairing it.
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).
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
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.
810 Further information about checksums can be found at:
811 <ulink url="http://en.wikipedia.org/wiki/Checksum"/>.
814 <section><title>Ethereal checksum validation</title>
816 Ethereal will validate the checksums of several potocols, e.g.: IP, TCP, ...
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.
824 Checksum validation can be switched off for various protocols in the
825 Ethereal protocol preferences, e.g. to (very slightly) increase
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
836 <section><title>Checksum offloading</title>
838 The checksum calculation might be done by the network driver, protocol
839 driver or even in hardware.
842 For example: The Ethernet transmitting hardware calculates the
843 Ethernet CRC32 checksum and the receiving hardware validates this
845 If the received checksum is wrong Ethereal won't even see the packet,
846 as the Ethernet hardware internally throws away the packet.
849 Higher level checksums are "traditionally" calculated by the protocol
850 implementation and the completed packet is then handed over to the
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.
859 <note><title>Note!</title>
861 Checksum offloading often causes confusion as the network packets to be
862 transmitted are handed over to Ethereal before the checksums are actually
864 Ethereal 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.
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.
876 You can do two things to avoid this checksum offloading problem:
880 Turn off the checksum offloading in the network driver, if this option is
886 Turn off checksum validation of the specific protocol in the Wireshark
896 <!-- End of WSUG Chapter Advanced -->