A city hall AP radio advertises several SSIDs on one BSSID. How should the protocol analyst scope filters when investigating only the staff BSS?
Select an answer to reveal the explanation.
Short Explanation
One radio can host several SSIDs like floors sharing an elevator shaft—you still need the right floor button. Filter to the staff SSID/BSS so guest chatter doesn’t muddy retries and roam stats. Averaging everything together or killing SSIDs for the capture just pollutes or disrupts service.
Full Explanation
One AP radio can advertise multiple SSIDs, each a distinct BSS from a service perspective even when co-located. When a city hall AP radio advertises several SSIDs on related BSSIDs, protocol analysis of the staff BSS must apply SSID- and BSS-specific filters so metrics and frames stay scoped to the staff BSS under investigation. Mixing guest and staff traffic averages hides the failure domain.
Filtering solely by channel number and ignoring SSID/BSSID fails by concept: co-channel SSIDs share spectrum but are different BSS conversations. Capturing every SSID and averaging metrics across guest and staff fails by concept: averages blur staff-specific faults with guest load. Disabling all SSIDs except guest for the duration of analysis fails by concept: that changes production service and investigates the wrong BSS relative to a staff problem.
Exam caveat: Multi-SSID municipal APs require BSS-scoped filtering; channel-only views are insufficient for staff versus guest root cause.
Operational check: Identify the staff BSSID/SSID from Beacons, apply display filters for that BSSID, exclude guest BSS traffic, and only then compute retry, EAP, or roam statistics for the city hall staff investigation.