[PATCH] Fix race conditions in the WPA group-key state machine

[Uri Simchoni]

Hi,
 
Working with madwifi driver, we've encountered some rare conditions in
which clients can't receive WPA-encrypted multicast packets. This has
become a more serious lately since Windows Vista uses broadcast packets
for DHCP by default.

After digging into it for a while, we realized that the group-key state
machine was stuck in the SETKEYS state, meaning that it negotiates a new
group key, but doesn't activate the key at the driver. Further
investigation showed that the GNoStations variable got negative.

Looking at all the possibilities of how this could happen I found that:
- Sometimes the individual station state machine doesn't get to run to
the end before being destroyed, GNoStations doesn't get decremented.
- The madwifi driver may send a deauth message to a non-associated
station. This may happen rarely since the actual destruction of the
station is deferred to a timer. The station is at the INITIALIZE state,
gets the deauth request, and decrements GNoStations once more. I fixed
the madwifi driver, but I think a similar bug exist in the other drivers
as well.

The supplied patch (against 0.4.10, sorry...) fixes these issues, and
also remove the reliance on GNoStations, because it looks like a
not-very-robust way to determine how many stations need to negotiate
group key (although it's based on the standard...)

Uri Simchoni
Sofaware Technologies
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wpa_patch.diff
Type: application/octet-stream
Size: 5316 bytes
Desc: wpa_patch.diff
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20080306/d546ae3e/attachment.obj