Misbehaving scanners at a city warehouse generate continuous Probe Request storms that congest airtime. What is the protocol-analysis concern?
Select an answer to reveal the explanation.
Short Explanation
A Probe Request storm is like hundreds of kids yelling 'is anyone home?' on the radio channel—everyone else waits their turn. Warehouse scanners stuck in that loop chew airtime even when they’re not sending real data.
Full Explanation
Misbehaving scanners at a city warehouse that generate continuous Probe Request storms congest airtime because excessive probing consumes contention and airtime, degrading capacity for legitimate BSS traffic. Management frames contend for the medium; storms are not “free.” Expert concern is capacity loss from pathological discovery behavior, then device remediation or rate/probe controls.
Claiming Probe Requests are wired-only frames and cannot affect RF airtime is false. Saying probe storms increase SNR for all clients by forcing higher MCS selection reverses typical impact—storms raise contention and errors. Asserting management frames never contend and only QoS data frames use EDCA ignores that probes still occupy the medium under DCF/EDCA access.
Exam caveat: probe storms are first-class airtime attackers in warehouse and logistics WLANs. Operational check: filter Probe Requests by scanner OUI/MAC, measure their airtime share, remediate firmware/config on the scanners, and confirm warehouse capacity recovers after the storm stops. Quarantine or rate-limit the offending scanners via NAC or vendor tools if firmware cannot be fixed quickly during peak warehouse hours. Measure airtime before and after scanner remediation during the same shift so warehouse supervisors see capacity recovery in operational terms.