A parks-and-recreation handheld joins the grounds SSID discovery list but never finishes a secure connection. The device profile is locked to TKIP-only while the AP is AES/CCMP-only per city policy. What is the fault?
Select an answer to reveal the explanation.
Short Explanation
If the radio speaks only TKIP and the AP speaks only AES, they never agree on a cipher. That encryption mismatch blocks the secure connect even when the SSID is visible. Update the client (or profile) to AES/CCMP to match policy.
Full Explanation
A parks-and-recreation handheld that joins the grounds SSID discovery list but never finishes a secure connection while locked to TKIP-only against an AES/CCMP-only AP has an encryption/cipher mismatch: TKIP-only client versus AES-only AP prevents a successful secure association. Discovery proves RF visibility; cipher negotiation failure blocks the secure path. City AES-only policy is incompatible with TKIP-only client locks.
SSID name case-insensitivity meaning cipher settings never affect connection fails by concept: ciphers are independent of SSID case rules and absolutely affect secure association. TKIP-only clients automatically upgrading to AES when they see a modern municipal AP fails because clients do not magically unlock forbidden ciphers. AES-only APs accepting TKIP clients when the passphrase is longer than eight characters invents a false length exception.
Exam caveat: heard SSID + failed secure connect often means cipher/AKM mismatch, not “Wi-Fi is down.”
Operational check: change the handheld profile to allow AES/CCMP (remove TKIP-only lock); verify association completes; confirm connection details show CCMP; retire TKIP-only images from parks inventory. Inventory parks handhelds still locked to TKIP-only and remediate images before citywide AES-only enforcement leaves field crews unable to finish secure association.