Wi-Fi Group-Key Rekey Failures: Isolate Security Handshakes from Data Power Saving

A device can exchange ordinary data successfully and still fail when the access point changes its group key. Diagnose that event as a security-state exchange: identify the rekey trigger, the per-station group-key messages, their processing outcome and the AP’s terminal decision. Treating every periodic disconnect as a beacon or DTIM problem skips the evidence needed to locate the failure.

This guide pins the AP behavior to hostapd 2.11 and the client reference to wpa_supplicant 2.11. It focuses on the RSN group-key handshake for an already associated station using a modern group cipher. Initial four-way authentication, PTK rekeying and master-key generation are separate events. Driver or firmware offload may move evidence below the supplicant, so the actual module, firmware and AP configuration remain part of every test record.

Identify the timer before interpreting periodicity

Hostapd 2.11 documents wpa_group_rekey as the GTK rekey interval. Its default is 86,400 seconds with CCMP/GCMP group ciphers; the legacy TKIP default differs. The configuration also contains wpa_gmk_rekey for the master key used to generate GTKs and wpa_ptk_rekey for pairwise keys. Do not infer which one fired solely from an approximate disconnect interval. Read the effective configuration and the event trace. hostapd 2.11, hostapd.conf WPA/RSN options

Strict group rekeying can also tie a change to a station leaving the BSS. Thus, an intermittent failure may correlate with another device’s departure rather than a fixed timer. Include station join/leave events and administrator-triggered changes in the test ledger. Record the selected group cipher, not just the pairwise cipher reported by a convenient status tool.

Use a handshake timeline with separate observations

Event	Evidence source	What it does not establish alone
AP begins a GTK update	Authenticator state and trigger log	That every station received the update
Group message 1/2 is sent or retried	AP trace and appropriately placed capture	That the client validated or installed anything
Client receives and processes the update	Supplicant or firmware key-management trace	That the AP accepted the client’s response
Group message 2/2 is accepted	Authenticator state completion	That application multicast delivery is healthy
Group handshake terminates in error	Authenticator error and disconnect reason	The precise RF, scheduling or key-processing root cause

A monitor capture can miss a frame because of channel coverage or receiver placement. A link-layer acknowledgment establishes a narrower observation than successful key-state processing. Keep “not seen in this capture,” “not received by the client,” and “received but rejected” as different conclusions. Prefer correlated AP and client state evidence over a single packet trace.

Read the retry and error contract precisely

The 2.11 configuration calls wpa_group_update_count the retry control for EAPOL-Key message 1/2 and documents a default of four. This is not an elapsed-seconds limit. The authenticator implementation tracks its group timeout counter and advances to the error state when its configured condition is met. Derive an observed timeline from the actual build rather than multiplying a guessed interval by that setting. hostapd 2.11, src/ap/wpa_auth.c group state machine

In the ordinary error path, hostapd marks the station for disconnection with a group-key-update-timeout reason. There is an explicit WPA2 exception when no_disconnect_on_group_keyerror is enabled. This guide’s expected-disconnect case assumes that exception is disabled. Otherwise, remaining associated does not prove the handshake succeeded; record the failure and resulting traffic behavior separately.

The wpa_disable_eapol_key_retries workaround changes retransmission behavior for key-installing frames, including group message 1/2, and uses an extended response timeout. Its documentation warns of reduced robustness, especially under load. Do not toggle it casually as a power-saving fix or recommend weakening key-update protection. Preserve its actual value and the vendor’s security rationale before interpreting missing retries.

Run a controlled three-condition campaign

1. Use an authorized isolated network. Keep an independent recovery path and a fixed software/configuration baseline. Choose a supported way to provoke a GTK update. Any temporary interval reduction is a laboratory setting, not a production recommendation.
2. Establish an awake baseline. Use the product’s supported awake configuration and light traffic. Correlate the trigger, group messages, client key-processing outcome and AP completion. A baseline failure should be resolved before investigating sleep interactions.
3. Repeat in the normal idle power state. Keep security settings and workload otherwise equivalent. Record actual client sleep/wake or firmware power-state evidence where available. A requested power-saving mode is not proof that the station entered it.
4. Repeat under representative load. Keep the radio/security baseline while exercising the target’s real CPU and data workload. Separate delayed client processing from over-air loss using both endpoint traces.
5. Verify the post-update data path. Test intended unicast and group traffic separately, with sequence-tagged test payloads. An accepted handshake followed by missing group delivery belongs in a different branch from an uncompleted handshake.

For every attempt, record the association epoch, rekey cause, effective retry settings, station power condition, message observations and terminal outcome. Avoid changing cipher, sleep policy, retry count and firmware together. That can create a passing run without identifying what fixed the failure.

A hypothetical diagnosis

Suppose a meter completes the awake case but disconnects during the idle case. The AP shows repeated group message 1/2 transmissions, while the client firmware trace shows no corresponding receive indication. This hypothetical result would justify investigating delivery and wake integration. It would not prove that increasing DTIM or disabling rekeying is appropriate.

If the client instead records receipt followed by a validation failure, inspect the reported replay, key-data or state mismatch with the vendor. If the client sends message 2/2 but the AP never accepts it, inspect the response path and authenticator rejection. If AP completion is proven, investigate subsequent key installation and group-data handling without relabeling that as an authentication timeout.

Close with a reproducible boundary

The configuration and state-machine claims were source-checked in the official 2.11 releases. No radio, sleeping station, rekey command or hardware timing test was executed for this article. The campaign above is proposed qualification work.

A useful closure identifies the first failing transition, the affected firmware/AP/configuration combination and a repeatable correction across all three conditions. Preserve security policy while qualifying that correction. A longer period before the next disconnect, or an associated-state indicator alone, is not evidence that GTK updates are reliable.