On Wed, 2015-05-20 at 22:55 +0200, Alexander Wetzel wrote: > I've verified that turning off hardware encryption on the AP and the STA > is indeed preventing the issue. > As soon as one of them is using the hardware encryption I can trigger > the problem. (In my setup it seems to be mostly caused by the AP, since > I needed sometimes as much as three rekeys to get the freeze when the AP > was using Software and the STA hardware encryption.) Right, I did identify cases where both sides can have issues. I'm not surprised that the AP-side issue is more likely. > So confident that we finally found the root of the evil I tried to write > some code catching the races, see the attachment. > > It's probably not the best fix, but the only one I could think of and > deploy myself with the knowledge I gathered here and the last days. Your patch breaks the security properties of this code, so we cannot use it :-) > What was really surprising me here is, that this is such a generic issue > and I'm finding that in my home environment. For my understanding that > should break many (all?) EAP Wlan's. (I'm using EAP-TLS and that did > make the WLAN basically unusable and any sane person would have switched > back to PSK...) Well, I think it's a matter of probabilities. First of all, the AP bug seems to be more likely to cause an issue, so anyone who deployed EAP-TLS with non-broken APs is far better off than you are. Secondly, you really can only run into this while you do rekeying in heavy traffic, so in production environments with large rekey intervals it doesn't matter as much again. And then I guess the windows driver reconnects on PTK rekey request, so there you wouldn't see it either ... as a consequence the number of affected people must be pretty low :) johannes -- 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
