Checksums may be carried out in various places. Recent Ethernet cards offload the checksums from the network stack. I have had to disable hardware checksumming to make network forensics easier. This should make obvious sense as without this functionality hardware would always silently drop packets.

Usually, the Ethernet level FCS (Frame Check Sequence) is handled in the hardware MAC (Media Access Controller). Note that we are talking about a CRC here and not just a checksum (there isn t a "checksum" at the Ethernet frame level).

If an FCS mismatch is detected, it will most probably be discarded at the HW MAC level: a statistics counter will then be updated.

In other words, it is no use "bothering" the software stack with an unusable frame.

As the other posters have said the FCS is normally checked by the NIC itself or by the driver. However, in the case where you read up raw ethernet frames I think it depends completely on the driver. For instance, in WiFi NICs that can be set in "monitor" or "promiscous" modes you usually don t want them to discard frames with bad FCS since that may signify an error that you are looking for.

One data point: the Intel 4965AGN Linux driver sets the FCS field in all captured packets to 0 in monitor mode. If you run Wireshark you can see that it calculates the expected FCS and complains that the 0-field is invalid. Wether this means that it discards frames with bad FCS in the MAC, or if those are also passed up is unfortunately unclear.

So if the original question is "Do I have to check the FCS myself when capturing raw packets" the answer in the 4965AGN case is "you can t", and may be "yes" if you get the real FCS from the NIC.

Most network hardware will allow you to set an option in the hardware to "store bad packets." This allows you to see packets in which the ethernet CRC failed. If you pass a bad ethernet frame to the stack, it will most likely be rejected due to a bad upper layer checksum. The stack does not check ethernet CRCs; this is left to the NIC, and CRC computation in software is time-consuming.

Keep in mind that stacked network protocols usually calculate checksums at various points in the stack. TCP will typically calculate a CRC at the network layer, IP header checksum at the IP layer, and TCP checksum at the TCP layer. The application may also verify the integrity of the data.