Wireshark-users: Re: [Wireshark-users] Bad Checksum Packet
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.
