The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
Disabling checksum validation in Wireshark
By stretch | Saturday, August 23, 2008 at 12:28 a.m. UTC
If you've worked with Wireshark for any amount of time you've likely been annoyed by false error markings as seen here:
Notice that all UDP packets generated by the local host (10.144.246.184) are displayed in red and black in the list view, and the details pane cites an incorrect checksum. The reason for this, as explained in the Wireshark wiki, is checksum offloading. Modern high-speed NICs support hardware checksum calculation for TCP and UDP. By performing these calculations in dedicated hardware, the burden is removed from the main CPU. This means the correct checksum value for an outgoing packet is applied only after Wireshark has captured its copy from the software TCP/IP stack, producing false error warnings in its output.
The obvious solution to this problem is to disable hardware checksum calculation, but that may cause performance problems, particularly under high throughput. Fortunately, there is a more appropriate solution: disable checksum validation in Wireshark. This can be accomplished by navigating to Edit > Preferences and expanding the Protocols list in the left pane to locate the TCP and UDP protocols. Under the options for each, uncheck the box enabling checksum validation.
After applying these changes, you'll have a much cleaner output in the list pane, allowing easier identification of real problems.
Posted in Packet Analysis, Tips and Tricks
Comments
August 23, 2008 at 11:08 a.m. UTC
Thank you! This has been bugging me for ever :)
August 23, 2008 at 2:12 p.m. UTC
One of the most annoying things about checksum validation, is that when you follow a TCP stream, it will exclude the packets that have a bad checksum. I think this is for good reason, but I have seen an empty stream when I knew data existed. I have then tracked that to the TCP checksum validation. Great point.
August 25, 2008 at 5:06 a.m. UTC
Thank you for this, I have been wondering about this and have spent a few hours trying to figure it out. But you write: "This means the checksum for outgoing packets is calculated after Wireshark has captured them, producing false error warnings in its output." I may not be thinking here now, but since the packet HAS been captured, and the checksum is checked AFTER wireshark has captured the packet, how can wireshark produce the error? I mean: The packet has left the building...
August 25, 2008 at 8:34 a.m. UTC
@Arnold: Put another way, the packet copied from the TCP/IP stack to Wireshark hasn't had its checksum calculated yet. The header field is populated by junk data (presumably whatever was left in the memory buffer); the correct checksum value is only filled in after the packet has been sent to the hardware NIC for transmission.
The wording is admittedly a bit fuzzy; I reworded that sentence to hopefully better illustrate the flow of a packet onto the wire.
August 27, 2008 at 8:19 a.m. UTC
If you are using wireshark on a 'sniffer' laptop i.e. connected to a spanned/mirrored port, I wouldn't expect to see the 'bad checksum error'. Since the checksum should have been correctly applied as now the frames are on the wire. Whereas when you are running Wireshark on the client/host you are monitoring, then wireshark runs at a high-layer (pre-checksum) and you get the error described. Do you agree?
PS> quality site, keep up the great work
August 27, 2008 at 8:38 a.m. UTC
@jagman: That's right. Checksum offloading only causes problems in frames sent from the monitoring host; anything captured from the wire won't be falsely flagged.
January 19, 2010 at 8:05 a.m. UTC
Same deal for IPv4 checksum validation.
May 4, 2010 at 1:32 p.m. UTC
My take on this is that collaborating NICS should have matching settings, otherwise there would be problems. In our case, the DCS equipment required that the checksum offload setting had to be None however the NIC on the other computer in the network where the DCS data was forwarded to had its NIC set differently and therefore the errors and actual trashing of packets reported by WireShark. Once we made the setting compatible, everything worked perfectly. Turning off the validation in WireShark would have been detrimental. We made uniform as well the Speed mode setting as once the checksum errors were cleared we detected another batch of errors that were originated because of the mismatched speed setting. With this latter change in one of the NIC cards the throughput went up to normal levels, not seen in this network before. So I would not blame it on WireShark, in fact we would have never been able to see a solution had this check been disabled.
June 24, 2011 at 10:53 a.m. UTC
Hi,
I guess the same happens to the FCS on the Ethernet frame. If you have observed, there is no CRC or FCS information on the Ethernet frames in the wireshark capture.
I believe the FCS is done at the NIC and hence not seen in the capture.
Thanks,
Mohan
July 19, 2011 at 9:56 a.m. UTC
Hi,Thanks jeremy for helping to understand the cheksum errors..I have a small query Although i have unchecked "validate UDP Checksum if possible" option still the messages are with BAD TCP color. and in detail messsage now i couldnt find any message with any error.
August 23, 2011 at 12:38 p.m. UTC
Funny coincidence! I had to do this yesterday and then today this article comes up in my [Replay] RSS feed! The only difference for me was that TCP and UDP checksum validation was already off by default, I had to turn off checksum validation for IP. Same process, but choose IP from the protocol list instead of TCP & UDP.
November 7, 2011 at 5:15 p.m. UTC
Hi, thank you Jeremy to understand the checksum error and since I've done wireshark re-discovered the http protocol :)
August 29, 2013 at 8:25 p.m. UTC
There is also an option to disable IPv4 checksum validation, which you may want to do in addition to disabling TCP/UDP checksum validation.