Movatterモバイル変換

Checksums are used to ensure the integrity of data portions for datatransmission or storage. A checksum is basically a calculated summary of such adata portion.

Network data transmissions often produce errors, such as toggled, missing orduplicated bits. As a result, the data received might not be identical to thedata transmitted, which is obviously a bad thing.

Because of these transmission errors, network protocols very often use checksumsto detect such errors. The transmitter will calculate a checksum of the data andtransmits the data together with the checksum. The receiver will calculate thechecksum of the received data with the same algorithm as the transmitter. If thereceived and calculated checksums don’t match a transmission error has occurred.

Some checksum algorithms are able to recover (simple) errors by calculatingwhere the expected error must be and repairing it.

If there are errors that cannot be recovered, the receiving side throws away thepacket. Depending on the network protocol, this data loss is simply ignored orthe sending side needs to detect this loss somehow and retransmits the requiredpacket(s).

Using a checksum drastically reduces the number of undetected transmissionerrors. However, the usual checksum algorithms cannot guarantee an errordetection of 100%, so a very small number of transmission errors may remainundetected.

There are several different kinds of checksum algorithms; an example of an oftenused checksum algorithm is CRC32. The checksum algorithm actually chosen for aspecific network protocol will depend on the expected error rate of the networkmedium, the importance of error detection, the processor load to perform thecalculation, the performance needed and many other things.

Further information about checksums can be found at:https://en.wikipedia.org/wiki/Checksum.

Wireshark will validate the checksums of many protocols, e.g., IP, TCP, UDP, etc.

It will do the same calculation as a “normal receiver” would do, and shows thechecksum fields in the packet details with a comment, e.g., [correct] or[invalid, must be 0x12345678].

Checksum validation can be switched off for various protocols in the Wiresharkprotocol preferences, e.g., to (very slightly) increase performance.

If the checksum validation is enabled and it detected an invalid checksum,features like packet reassembly won’t be processed. This is avoided asincorrect connection data could “confuse” the internal database.

The checksum calculation might be done by the network driver, protocol driver oreven in hardware.

For example: The Ethernet transmitting hardware calculates the Ethernet CRC32checksum and the receiving hardware validates this checksum. If the receivedchecksum is wrong Wireshark won’t even see the packet, as the Ethernet hardwareinternally throws away the packet.

Higher-level checksums are “traditionally” calculated by the protocolimplementation and the completed packet is then handed over to the hardware.

Recent network hardware can perform advanced features such as IP checksumcalculation, also known as checksum offloading. The network driver won’tcalculate the checksum itself but will simply hand over an empty (zero orgarbage filled) checksum field to the hardware.

Note

Checksum offloading often causes confusion as network packets to betransmitted are given to Wireshark before they are handed over to thehardware. Wireshark gets these “empty” checksums and displays them asinvalid, even though the packets will contain valid checksums when theytransit the network. This only applies to packets that are locally generated by the capturepoint. Received packets will have traveled through network hardwareand should have correct checksums.

Checksum offloading can be confusing and having a lot of [invalid] messages onthe screen can be quite annoying. As mentioned above, invalid checksums may leadto unreassembled packets, making the analysis of the packet data much harder.

You can do two things to avoid this checksum offloading problem:

TCP and UDP checksums are calculated over both the payload and from selectedelements from the IPv4 or IPv6 header, known as the pseudo header. Linuxand Windows, when offloading checksums, will calculate the contribution fromthe pseudo header and place it in the checksum field. The driver then directsthe hardware to calculate the checksum over the payload area, which willproduce the correct result including the pseudo header’s portion of the sumas a matter of mathematics.

This precomputation speeds up the hardware checksum calculation later,allows the driver to direct the hardware to do checksums over encapsulatedpayloads (Local Checksum Offload), and allows applications to sendthe kernel large "superpacket" buffers that will be later divided bythe hardware into multiple maximum size packets when sent on the network(TCP Segmentation Offload (TSO) andGeneric Segmentation Offload (GSO)).

Note

Wireshark 4.2.0 and later can calculate the partial checksum contributionfrom the pseudo header, and when validating TCP and UDP checksums willmark partial checksums as valid but partial. The packets with partialchecksums will not be colored as Bad Checksums by the default coloring rules,and will still be used for reassembly. This eliminates spurious checksumerrors seen on packets transmitted from the capturing host on those platformsthat use partial checksums when offloading.