path: root/hostapd/wpa_auth_i.h
Commit message (Collapse)AuthorAgeFilesLines
* Cleaned up EAPOL-Key timeout processingJouni Malinen2008-12-181-1/+1
| | | | | | | | | | | | | | | | | dot11RSNAConfigGroupUpdateTimeOut and dot11RSNAConfigPairwiseUpdateTimeOut MIB variables were only used in draft versions of IEEE 802.11i, so rename these in order not to use confusing name here. Replaced EAPOL-Key timeout to use following timeouts (in milliseconds): 100,1000,1000,1000 (this was 1000,1000,1000,0). There is no point in sending out the final EAPOL-Key frame which would be immediately followed by disconnection. After the change to allow response to any pending EAPOL-Key frame, it is fine to send the first retransmission quickly to avoid long wait in cases where Supplicant did not receive the first frame for any reason. The new sequence will still provide 3.1 seconds of time to get any response frame, so this does not reduce the previous time.
* Improve EAPOL-Key handshake stability with retransmitted framesJouni Malinen2008-12-161-2/+7
| | | | | | | | | | | | | | | | | | | Accept response to any pending request, not just the last one. This gives the Supplicant more time to reply since hostapd will now allow up to three seconds for the reply to the first EAPOL-Key frame transmission (and two seconds for the first retry and one second for the last) while the previous version invalidated any old request immediately when sending a retransmitted frame. If the Supplicant replies to more than one request, only the first reply to arrive at the Authenticator will be processed. As far as the Supplicant is concerned, this behavior does not differ from the previous one except for being less likely to cause unneeded retransmissions of EAPOL-Key frames. This can help in cases where power saving is used when the group key is rekeyed or when there is excessive traffic on the channel that can delay (or drop) EAPOL-Key frames.
* Fix group key rekeying when reauth happens during pending group key updateJouni Malinen2008-10-211-0/+1
| | | | | | | | We need to cancel the group key update for a STA if a reauthentication request is received while the STA is in pending group key update. When canceling the update, we will also need to make sure that the PTK Group Key state machine ends up in the correct state (IDLE) to allow future updates in case of WPA2.
* Added support for opportunistic key caching (OKC)Jouni Malinen2008-08-031-0/+3
| | | | | This allows hostapd to share the PMKSA caches internally when multiple BSSes or radios are being controlled by the same hostapd process.
* Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 releaseJouni Malinen2008-02-281-0/+212