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 the checksum 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 Wireshark protocol 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 as incorrect connection data could “confuse” the internal database.

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

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.

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

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.

Note

Checksum offloading often causes confusion as network packets to be transmitted are given to Wireshark before they are handed over to the hardware. Wireshark gets these “empty” checksums and displays them as invalid, even though the packets will contain valid checksums when they transit the network. This only applies to packets that are locally generated by the capture point. Received packets will have traveled through network hardware and should have correct checksums.

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.

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

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

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

Note

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