After a library WLAN profile change, Probe Responses for the public SSID lack the expected RSN information element. What is the most useful first split for the CWNE analyst?
Select an answer to reveal the explanation.
Short Explanation
If the Probe Response forgot its security badge, check whether the AP profile actually applied before you blame drywall. Missing RSN usually means config drift or a misapplied WLAN profile, not a mysterious RF eraser. Turning up rates or waving antennas won’t invent an IE that isn’t configured.
Full Explanation
Probe Responses should carry the security advertisement clients use to decide whether and how to join. After a library WLAN profile change, if Probe Responses for the public SSID lack the expected RSN information element, the most useful first split is to treat the missing RSN IE as a configuration or profile validation issue before chasing RF coverage as the root cause. A profile that no longer emits RSN will break or alter secure join regardless of strong RSSI.
Assuming multipath in the stacks wiped the RSN IE and retuning only antennas fails by concept: multipath does not selectively strip one IE while leaving a coherent Probe Response as a coverage-first story. Concluding that 802.11 management frames never carry security IEs fails by concept: RSN IEs are standard in Beacons/Probe Responses for robust security networks. Raising minimum data rates citywide to force RSN fields to reappear fails by concept: basic rates do not regenerate missing security IEs from a bad profile.
Exam caveat: Missing security IEs after a controller/profile change are classic config regressions; CWNE triage puts profile validation ahead of RF walks.
Operational check: Compare pre/post profile Probe Responses for the public library SSID, verify RSN IE presence against intended WPA2/WPA3 policy, and correct the WLAN profile before scheduling a coverage survey.