A school-district AP still allows mixed TKIP/AES for a legacy SSID, but a new teacher laptop policy demands AES-only. The laptop refuses to connect. What should the technician address?
Select an answer to reveal the explanation.
Short Explanation
Mixed TKIP/AES on the AP versus an AES-only client policy is a cipher standoff. Align both sides to modern AES/CCMP per district rules. Hiding the SSID or twiddling beacons won’t invent a matching cipher.
Full Explanation
A school-district AP that still allows mixed TKIP/AES on a legacy SSID while a new teacher laptop policy demands AES-only—and the laptop refuses to connect—requires resolving the cipher policy mismatch so the client’s AES-only requirement and the AP’s offered ciphers align. Modern client policy will not accept a negotiation that cannot settle on an allowed suite. Technicians align AP and client to the approved AES/CCMP path rather than weakening the laptop.
Ignoring cipher settings and raising beacon interval until the laptop associates fails because beacon interval does not fix cipher policy refusal. Forcing the laptop to TKIP-only to match the oldest cipher the mixed AP still prefers fails by concept and violates modern AES-only policy. Disabling SSID broadcast so hidden SSIDs bypass all encryption negotiation problems fails: hiding does not skip cipher negotiation.
Exam caveat: AES-only clients vs mixed/legacy AP offerings = encryption configuration problem.
Operational check: set the AP SSID to AES/CCMP required (disable TKIP) per district policy; confirm the teacher laptop associates; verify CCMP in connection details; schedule legacy device upgrades still needing TKIP onto an isolated exception SSID if absolutely required.