A parks-department scanner’s Association Request shows no HE capabilities, yet the AP continues to advertise HE-only features for that BSS. What diagnosis should guide remediation?
Select an answer to reveal the explanation.
Short Explanation
The AP is speaking Wi-Fi 6 slang while the old scanner still speaks classic—interop breaks when features assume HE that the client never offered. Match BSS options to what the client can actually signal, or expect join and throughput pain. Longer Beacons or turning off Acks won’t teach a non-HE radio new tricks.
Full Explanation
Association and performance depend on intersecting client and AP capability sets. When a parks-department scanner's Association Request shows no HE capabilities yet the AP continues to advertise HE-only features for that BSS, remediation should recognize a client/AP capability mismatch that can limit join success or performance, then adjust BSS features or client expectations accordingly. HE-only assumptions fail when the handheld fleet cannot advertise HE.
Forcing every scanner onto 6 GHz only so HE IEs become irrelevant fails by concept: many scanners lack 6 GHz/HE, and band moves do not fix a BSS that demands unsupported features. Disabling all acknowledgments because non-HE clients cannot decode Block Ack fails by concept: acknowledgments remain fundamental; non-HE clients still use appropriate BA/Ack mechanisms without turning Ack off. Increasing Beacon interval to 1000 TU to auto-negotiate HE for legacy scanners fails by concept: Beacon interval does not grant HE capabilities to non-HE clients.
Exam caveat: Capability mismatch questions reward reading Association Request versus Beacon IE sets and aligning municipal BSS mode with the real device inventory.
Operational check: Diff the scanner Association Request capabilities against the parks BSS Beacon HE/HT/VHT IEs, decide whether to enable backward-compatible modes or refresh the handheld fleet, and retest join and throughput after the policy change.