/usr/share/doc/wireshark-doc/wsug_html_chunked/ChAdvChecksums.html is in wireshark-doc 1.6.7-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 | <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>7.8. Checksums</title><link rel="stylesheet" type="text/css" href="ws.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"><link rel="home" href="index.html" title="Wireshark User's Guide"><link rel="up" href="ChapterAdvanced.html" title="Chapter 7. Advanced Topics"><link rel="prev" href="ChAdvNameResolutionSection.html" title="7.7. Name Resolution"><link rel="next" href="ChStatistics.html" title="Chapter 8. Statistics"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">7.8. Checksums</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ChAdvNameResolutionSection.html">Prev</a> </td><th width="60%" align="center">Chapter 7. Advanced Topics</th><td width="20%" align="right"> <a accesskey="n" href="ChStatistics.html">Next</a></td></tr></table><hr></div><div class="section" title="7.8. Checksums"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="ChAdvChecksums"></a>7.8. Checksums</h2></div></div></div><p>Several network protocols use checksums to ensure data
integrity.</p><div class="tip" title="Tip!" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Tip: Tip!"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Tip]" src="wsug_graphics/tip.png"></td><th align="left">Tip!</th></tr><tr><td align="left" valign="top"><p>Applying checksums as described here is also known as
<span class="command"><strong>redundancy checking</strong></span>.</p></td></tr></table></div><div class="sidebar" title="What are checksums for?"><div class="titlepage"><div><div><p class="title"><b>What are checksums for?</b></p></div></div></div><p>Checksums are used to ensure the integrity of data
portions for data transmission or storage. A checksum is
basically a calculated summary of such a data portion.</p><p>Network data transmissions often produce errors, such
as toggled, missing or duplicated bits. As a result, the data
received might not be identical to the data transmitted,
which is obviously a bad thing.</p><p>Because of these transmission errors, network protocols
very often use checksums to detect such errors. The
transmitter will calculate a checksum of the data and
transmits the data together with the checksum. The receiver
will calculate the checksum of the received data with the
same algorithm as the transmitter. If the received and
calculated checksums don't match a transmission error has
occurred.</p><p>Some checksum algorithms are able to recover (simple)
errors by calculating where the expected error must be and
repairing it.</p><p>If there are errors that cannot be recovered, the
receiving side throws away the packet. Depending on the
network protocol, this data loss is simply ignored or the
sending side needs to detect this loss somehow and
retransmits the required packet(s).</p><p>Using a checksum drastically reduces the number of
undetected transmission errors. However, the usual checksum
algorithms cannot guarantee an error detection of 100%, so a
very small number of transmission errors may remain
undetected.</p><p>There are several different kinds of checksum
algorithms; an example of an often used checksum algorithm is
CRC32. The checksum algorithm actually chosen for a specific
network protocol will depend on the expected error rate of
the network medium, the importance of error detection, the
processor load to perform the calculation, the performance
needed and many other things.</p><p>Further information about checksums can be found at:
<a class="ulink" href="http://en.wikipedia.org/wiki/Checksum" target="_top">http://en.wikipedia.org/wiki/Checksum</a>.</p></div><div class="section" title="7.8.1. Wireshark checksum validation"><div class="titlepage"><div><div><h3 class="title"><a name="idp18257360"></a>7.8.1. Wireshark checksum validation</h3></div></div></div><p>Wireshark will validate the checksums of several
protocols, e.g.: IP, TCP, UDP, ...</p><p>It will do the same calculation as a "normal receiver"
would do, and shows the checksum fields in the packet details
with a comment, e.g.: [correct], [invalid, must be
0x12345678] or alike.</p><p>Checksum validation can be switched off for various
protocols in the Wireshark protocol preferences, e.g. to
(very slightly) increase performance.</p><p>If the checksum validation is enabled and it detected
an invalid checksum, features like packet reassembling won't
be processed. This is avoided as incorrect connection data
could "confuse" the internal database.</p></div><div class="section" title="7.8.2. Checksum offloading"><div class="titlepage"><div><div><h3 class="title"><a name="idp18259232"></a>7.8.2. Checksum offloading</h3></div></div></div><p>The checksum calculation might be done by the network
driver, protocol driver or even in hardware.</p><p>For example: The Ethernet transmitting hardware
calculates the Ethernet CRC32 checksum and the receiving
hardware validates this checksum. If the received checksum is
wrong Wireshark won't even see the packet, as the Ethernet
hardware internally throws away the packet.</p><p>Higher level checksums are "traditionally" calculated
by the protocol implementation and the completed packet is
then handed over to the hardware.</p><p>Recent network hardware can perform advanced features
such as IP checksum calculation, also known as checksum
offloading. The network driver won't calculate the checksum
itself but will simply hand over an empty (zero or garbage filled)
checksum field to the hardware.</p><div class="note" title="Note!" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note: Note!"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="wsug_graphics/note.png"></td><th align="left">Note!</th></tr><tr><td align="left" valign="top"><p>Checksum offloading often causes confusion as the
network packets to be transmitted are handed over to
Wireshark before the checksums are actually calculated.
Wireshark gets these "empty" checksums and displays them as
invalid, even though the packets will contain valid
checksums when they leave the network hardware
later.</p></td></tr></table></div><p>Checksum offloading can be confusing and having a lot
of [invalid] messages on the screen can be quite annoying. As
mentioned above, invalid checksums may lead to unreassembled
packets, making the analysis of the packet data much
harder.</p><p>You can do two things to avoid this checksum offloading
problem:
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Turn off the checksum offloading in the network
driver, if this option is available.</p></li><li class="listitem"><p>Turn off checksum validation of the specific
protocol in the Wireshark preferences.</p></li></ul></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ChAdvNameResolutionSection.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ChapterAdvanced.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ChStatistics.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">7.7. Name Resolution </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 8. Statistics</td></tr></table></div></body></html>
|