Peer maps from a courthouse SSID capture show an unexpected STA exchanging large volumes of data with many peers it should not. What is the most appropriate protocol-analysis use of that peer-map evidence?
Select an answer to reveal the explanation.
Short Explanation
Peer maps are the seating chart of who talks to whom. When a stranger is chatting up half the courtroom Wi-Fi, that's your cue to hunt a rogue or mis-joined device—not to shrug it off as Bluetooth trivia.
Full Explanation
Peer maps and conversation statistics summarize which stations exchange traffic with whom and in what volume. On a courthouse SSID, an unexpected STA talking heavily to many peers it should not is most appropriately treated as abnormal communication pattern evidence that may indicate a rogue, misassociated, or compromised device on the secured network. Protocol analysis uses that map to prioritize investigation, not to leap to unrelated RF conclusions.
Saying peer maps only measure Bluetooth coexistence fails by concept: peer maps in 802.11 analyzers reflect Wi-Fi talkers and conversations, not a Bluetooth-only metric. Claiming unexpected talkers always mean the RADIUS shared secret rotated and must be ignored fails by concept: shared-secret problems affect authentication success, not a reason to discard abnormal peer graphs. Treating high peer counts as proof of DFS radar requiring immediate channel abandonment fails by concept: DFS is signaled through radar detection and channel-switch mechanisms, not peer-map fan-out.
Exam caveat: Statistical views guide where to look; they are not automatic proof of a specific attack or regulatory event. CWNE judgment correlates peer anomalies with identity, association state, and authorized device inventory.
Operational check: Export top talkers and peer counts for the courthouse BSS, match MACs to asset inventory and association tables, and capture follow-up frames for any STA with unexplained many-to-many data before containment actions.