Hi, > We don't flush the queues when we get the EAPOL packet, we flush the queue when > we get the .add_key cfg80211 call, so we can be sure that the EAPOL packet has > already been encapsulated by the MAC before we install the new key. > > We can already do this ring flush in .add_key, but we don't really know for > certain that the handshake packet has reached the driver's ring yet (at least, I > do not understand the kernel's network stack well enough to convince myself that > it must have). With .tx_control_port, we know for sure that it has. > > We could do some insane hacks with existing information, like "we've seen an > EAPOL frame of type XYZ, so we know an .add_key call should be on the way (or > maybe we've already had it, because the frame got delayed somehow in the kernel > network stack?) so we can somehow order the actioning of the .add_key vs the > transmission of the EAPOL" but I hope you'll agree with my characterisation as > "insane" :D Right, that's basically what I was thinking of when I said there were race conditions. Yes, I agree :) > Well my fear was that there could be a driver that relies on something like: > > if (skb->protocol == htons(ETH_P_PAE)) > /* explicitly disable encryption for this frame */ > > > in its .ndo_start_xmit, to avoid the race condition vs key installation. That's basically every driver. I guess you have this problem only because you can't tag that specific frame for "no encryption" or something like that? > But > then it implements .tx_control_port and respects the noencrypt flag (but doesn't > flush its TX queues in .add_key). I don't think any implement it now, really. I'm also not sure why the flush queues should be important. Ohh. You're thinking of the *other* rekey race now, because of the reuse of the key index ... but as you said, that one is fundamentally unsolvable, we have to get the extended key ID support for that. So I guess I think this is fine. I do think somebody will eventually need the ability to *NOT* set the NL80211_ATTR_CONTROL_PORT_NO_ENCRYPT flag in the future, but I guess they can worry about that. johannes _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
