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. _______________________________________________ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
