On Fri, May 15, 2015 at 9:35 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Fri, 2015-05-15 at 10:52 +0300, Emmanuel Grumbach wrote: >> >> I'd be glad if someone could take a look. If not, I'll have someone >> >> from our team to look at it, but I don't know how long it will take... >> > >> > Without looking too much - it seems to me that this is a fundamental >> > problem with PTK rekeying, in that it re-uses the key index that is >> > intended to avoid this. >> >> In this case, the AP is openWRT. I guess the Key idx is chosen in >> software, so maybe the proper fix would be to have openWRT increment >> the key index when it rekeys? > > Neither the spec nor the code allow that. > I don't get it. I might have misunderstood your previous mail, but I thought that you were saying the key index was meant to solve this: the peer could know what key was used based on the key index written in the frame (I guess it is there somehow) so that the Rx handling code can know that the jump in the PN is due to a rekeying and not use any heuristic. I though you meant that the Txing side had a poor implementation because it reused the same key index before and after the rekeying which can obviously lead to problems. Now you seem to say that changing the key index upon rekeying is not allowed by spec? What is it good for then? Again - I am just trying to close this bug, not to learn this subject. I can learn by reading spec / reading code and less by wasting your time :) -- 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
