On Tuesday 14 June 2011 16:47:45 ShawnG wrote: > I forgot to ask this, does the AR9170 hardware FCS calculation have a bug, > because we see garbage packets quite frequently? Depends on how you operate the device [as client or AP, with 11n-draft or just b/g]. Obviously, if you use HW crypto offload [default] on one interface and capture frames on an extra monitor interface on the same device, the FCS will always be wrong for protected data frames because the HW has already decrypted the frame, but left the original FCS [for the encrypted frame] in place. Also, you should tell your capture tool not to enable promisc mode [most enable it by default], because this also affects the FCS check. So much for the "duh!" cases. However, this might not be the whole story, in fact I've seen weird data frames as well [with different HW, but no matter]. I don't think the FCS check per se is buggy. The hardware seems to receive and verify the frames just fine, but somehow the frame's content get corrupted along the way to the driver. [Note: The reason why I think this is more likely is because the hardware also "sends" occasionally garbage frames but with a correct FCS! this was detected by a case we had a while ago: mac80211: ignore non-bcast mcast deauth/disassoc frames"] What I don't know if behavior is caused by a incorrect register value somewhere, or by a hardware bug. However, if you have a "normal" PC, you can always set nohwcrypt=1. This will fix the issue for good, because the garbage data frames will then be dropped by the message integerty check. Regards, Chr -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
