Wireless: SonicPoint EAPOL-Key timeout troubleshooting steps using SP logs and Client Connectivity

03/26/2020 7 8044

DESCRIPTION:

Sonic Point EAPOL-Key troubleshooting steps using SP 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.