[Guy Harris <guy@xxxxxxxxxxxx>]

Andreas Fink wrote:

> in todays wired networks its rather rare to see invalid checksums 
> because it would mean that  a packet get transmitted and received but 
> incorrectly received due to a bad wire o the like.

The same applies for 802.11 wireless networks, at least - you might be 
more likely to get incorrectly-received packets, but the 802.11 adapter 
would probably discard it before handing it to the host, because of a 
bad link-layer CRC (just as would be the case on modern wired LANs and 
WANs).  I suspect that's the case for at least some other wireless 
networks (various mobile phone data networks, WiMAX, etc.).

> So its very unlikely to see tcp.checksum_bad == 1 unless you have a 
> broken TCP stack creating wrong checksums or the like.

...or the hardware passes packets with bad link-layer checksums to the 
host (either by default or because the driver configured it to do so), 
and the driver arranges that they be provide to the packet capture 
mechanism used by libpcap/WinPcap and thus by Wireshark/TShark.  Many 
capture mechanisms are part of the networking stack, and might not be 
designed to allow that (i.e., if the driver passes the packet to the 
networking stack, it might also get supplied to the IP layer and thus 
the TCP layer, even though it's known to be bad), but the BPF mechanism 
in *BSD/OS X/AIX is separate from the rest of the networking stack, and 
I think at least some drivers on some *BSDs will, in promiscuous mode, 
configure the adapter to supply packets with bad CRCs to the host and 
will provide those packets to BPF, and thus to libpcap and ultimately to 
tcpdump/Wireshark/TShark/etc..

However, there's no way to control that behavior, as far as I know 
(other than to turn promiscuous mode on if the driver *already* supports 
it), and, on most platforms, I don't think that behavior is available.