wpa keyhandshake question/bug (patch)

[Sebastian Weitzel]

> How often does this happen (e.g., percentage of attempts) and how much
> other traffic was being transmitted during reauthentication?

It is very noticable in an outdoor scenario with many accesspoints and 
many customers (about 10-20) connected to each ap. We have eap reauth 
interval set to 600 seconds in the outdoor scenario. I approx. it 
happens every second - to third reauth.

I changed my test scenario to eap-reauth interval of 30 seconds to 
reproduce this behaviour in indoor tests. I was able to reproduce when 
connecting just one client to a madwifi ap and doing some traffic 
(iperf or ping flood, but shaped to 3MBit e.g. is sufficient). I think 
prism is also hit by this issue.
> IEEE 802.11i-2004 does not use Group Key handshake directly after 4-Way
> Handshake; this mechanism is only used with WPA.. Are you talking about
> WPA or WPA2?

I am talking about and using WPA. I dont tested WPA2 yet, because I 
fear incompatibilities with windows clients.

> Yes, the first case should rely on lower layer retransmission. It might
> be useful to use a lower transmit rate and larger retry count for EAPOL
> frames in order to make them less likely to be dropped.

EAPOL packets are now (since some weeks) send with lowest rate in 
madwifi. But this doesnt fixed the issue, but may helped a bit.

> The AP will likely retransmit msg 3/4 if it does not receive msg 4/4.
> However, this msg 3/4 is using the old key (or plaintext for the first
> 4-Way Handshake). Drivers could make this more robust by storing the
> previously used key for short period of time after key change and trying
> to use it to decrypt packets that fail decryption with the new key. This
> would allow the retransmitted msg 3/4 to go through.

I also thought about modifying the driver but I came to the conclusion 
that this is not perfect because not always possible. I did a patch 
which hacks a bit in the EAPOL State machine regarding retries.

I changed it to the following: If the 4/4 packet from the sta is lost 
(I mean the AP has hit dot11RSNAConfigPairwiseUpdateCount) then I just 
force to assume 4/4 is received and continue in the state machine. This 
helped much in my scenario. And I dont see any side effects. If the 3/4 
did not reach the sta then
there develops a inconsistent state because the ap doesnt gets 4/4 from 
sta and assumes answer got lost and procedes (with setting the new 
key), but in my scenario at least this happens once in a hundred tries. 
If it happens the connection will reestablished in a few seconds.

(see the link in the last line to the attachment).

Regards,
Sebastian Weitzel

-----
Anhänge (Die Links sind bis zum December 1, 2005 gültig)
http://webmail.togg.de/imp/attachment.php?u=togg&t=1115741888&f=11.hostap-set-key.patch