When receiving a raw ethernet packet over a wireless connection, where does the ethernet checksum get calculated, and where are errors handled?
Does the wireless stack handle this, or is it handled in the upper layers?
+1
A:
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.
jldupont
2009-12-08 16:19:41
+1
A:
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.
Hassan Syed
2009-12-08 16:30:23
A checksum is **not** a CRC: the question is specific to Ethernet ( and **not** the client protocols).
jldupont
2009-12-08 18:22:04
The article I linked to does not differentiate between the two.
Hassan Syed
2009-12-08 18:25:32
@Hassan Syed: then the article doesn't cover the question at hand here.
jldupont
2009-12-08 19:55:20
if they consider a CRC32 to belong to the category of checksum then yes it does. You assert that it doesn't. I have had to search for the disabling of hardware CRC32 in the past, and I recall using the same terminology. "A rose by any any other name...." ? Why are we arguing these irrelevant semantics ? Checksums and CRC32 both check for errors in a payload
Hassan Syed
2009-12-08 20:27:49
Still, a checksum is very different from a crc and more so when it comes to implementing one: in HW, a CRC is easy to implement whereas in software, it is very slow.
jldupont
2009-12-10 03:24:41
A:
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.
Per Ekman
2009-12-09 08:51:03
A:
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.
WhirlWind
2010-03-31 19:32:43