Wireless: SonicWave EAPOL-Key timeout troubleshooting steps using SP logs and Client Connectivity
Description
SonicWave EAPOL-Key troubleshooting steps using AP logs...
Client Connectivity
---------------------------
We can see the below client dis-connectivity in sonic point logs when 802.1x is used (AES and TKIP).
10:02:b5:29:ce:df WPA: sending 3/4 msg of 4-Way Handshake
May 5 13:00:14 (none) daemon.debug hostapd: ath11: STA 10:02:b5:29:ce:df WPA: EAPOL-Key timeout
May 5 13:00:14 (none) daemon.debug hostapd: ath11: STA 10:02:b5:29:ce:df WPA: sending 3/4 msg of 4-Way Handshake
May 5 13:00:14 (none) daemon.debug hostapd: ath11: STA 10:02:b5:29:ce:df IEEE 802.1X: unauthorizing port
May 5 13:00:14 (none) daemon.info hostapd: ath11: STA 10:02:b5:29:ce:df IEEE 802.11: deauthenticated due to local deauth request
May 5 13:00:14 (none) daemon.debug hostapd: ath11: STA 10:02:b5:29:ce:df WPA: strict rekeying - force GTK rekey since STA is leaving
May 5 13:00:14 (none) daemon.info hostapd: ath11: STA 10:02:b5:29:ce:df IEEE 802.11: disassociated
May 5 13:00:14 (none) daemon.debug hostapd: ath11: WPA rekeying GTK
EAPOL-Key Timeout value, the default is 1 second or 1000 milliseconds.
What this means is when it comes time to exchange the EAPOL keys between the AP and client, the AP will send the key and wait up to 1 second by default for the client to respond.
After waiting the defined time value, the AP will re-transmit the key again.
1 - AP sends key attempt to the client
2 - Wait 1 second for a reply
3 - If no reply, then send eapol key retry attempt #1
4 - Wait 1 second for a reply
5 - If no reply, then send eapol key retry attempt #2
6 - If there is still not a response from the client and the retry value is met, then de-authenticate the client.
Again, as with the EAPOL-Key Timeout, extending the EAPOL-Key retry value could in some circumstances be beneficial, however setting it to the max may again be harmful as the de-authenticate message would be prolonged.