[PATCH] Fix race conditions in the WPA group-key state machine
Wed Mar 5 23:18:46 PST 2008
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
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...)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5316 bytes
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20080306/d546ae3e/attachment.obj
More information about the Hostap