[PATCH] rsn_supp: Don't encrypt EAPOL-Key 4/4.

[Nicolas Cavallari]

>> Anyway, it won't solve Andreas' problem : the 4/4 frame is queued behind
>> a handful of data frames, control is resumed to wpa_supplicant, which
>> sets the key just after. When the kernel flush his queue, it already
>> uses the new key, so sends 4/4 encrypted with the new PTK ...   Solving
>> this might require something more than just "setprotection".
> 
> What were those other data frames? If this is during the initial 4-way
> handshake, the port (PAE) should be unauthorized and other data frames
> apart from EAPOL frames should be blocked.

Only the specific port corresponding to that particular authenticator is
blocked. Other ports from other authenticators may be open. This is not
the case for Andreas, as he is in Infrastructure mode. But for me it is,
in IBSS mode...

> As far as rekeying is concerned, this gets quite a bit more
> complex (until the newly defined non-zero key index PTK gets into use).

Which standard is this ? I might want to implement this for my
private IBSS network.