Disabling checksum validation in WiresharkPosted by stretch in Tips and Tricks on Saturday, 23 Aug 2008 at 12:28 a.m. GMTIf 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.
|
Navigation
Armory
Online Toolbox
|
Thank you! This has been bugging me for ever :)
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.
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...
@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.
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
@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.