Antonio Quartulli wrote: > What patch is addressing this change? And can could please explain a > bit more about what is needed to address the key cache corruption problem? > > Right now I am working on a "reactive behavior" which tries to detect > a cache corruption event and subsequently re-install all the keys one > by one to ensure they are back to a proper state. > > What does this ALWAYS_PERFORM_KEY_SEARCH bit do? Is it set within the > initvalues? Normally, key search for decryption is done by the HW only for the first frame in an aggregate. Enabling ALWAYS_PERFORM_KEY_SEARCH makes the HW do a key lookup for each sub-frame in aggregate. This is one step in addressing the key cache corruption problem, but it comes at a cost. The HW MAC is stressed more when this bit is enabled, especially when the number of associated clients is high. This issue was first seen in AR9300 and I don't think it has been fixed in any later chip since the workaround of enabling ALWAYS_PERFORM_KEY_SEARCH works fine in actual usage. But, in some high-interference environments, the key cache gets corrupted and large number of decrypt errors are seen. The root cause is not known and the workaround is to set all the keys in the HW again, when this happens. Still, this is not sufficient and sometimes decrypt errors are not received at all from the HW, since the flags in the RX descriptor are mangled, so just monitoring the RX path in the driver is not enough and a periodic timer comparing the HW keys with the driver is needed. If any mismatch is seen, the keys are programmed again in the HW. So, if ALWAYS_PERFORM_KEY_SEARCH is enabled, we need to see how the driver/HW performs with 16 associated clients or more. Internally, it was enabled on a per-project basis, but it has been enabled by default recently. But, I think this should be tested properly. As for the RX-path/timer workaround, it's just a nasty hack. :-) Sujith -- 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
