A city public-safety SSID capture shows the 4-way handshake failing around message 3/4. Conceptually, what should the expert isolate next?
Select an answer to reveal the explanation.
Short Explanation
The 4-way handshake is a lock-and-key ceremony—message 3/4 is where the new PTK actually gets installed and confirmed. When that step flakes, stop blaming DHCP and ask whether the AP or the client dropped the keys on the floor.
Full Explanation
On a city public-safety SSID capture where the 4-way handshake fails around message 3/4, the expert should isolate whether PTK installation or key confirmation fails at the AP or client after EAP success—focusing on message 3/4 exchange integrity rather than restarting only DHCP. Messages 3 and 4 complete pairwise key installation/confirmation; failures here are key-management problems, not IP lease problems. Public-safety SSIDs need precise handshake triage under operational pressure.
Skipping straight to replacing all antennas because handshake message numbers map one-to-one to spatial streams invents a PHY mapping that does not exist. Claiming message 3/4 failures only occur when Beacons omit TIM bits so power-save must be disabled globally misattributes keying to TIM. Treating any failure after message 2 as proof that OWE is mandatory and 802.1X must be removed abandons enterprise authentication incorrectly.
Exam caveat: know 4-way message roles; EAP success ≠ data-plane readiness until 3/4 complete. Operational check: capture a failing public-safety join, mark EAP success versus M3/M4 retries or MIC failures, compare AP and client system times/logs, and remediate key install issues before DHCP or antenna swaps.