What Your AP's GUI Doesn't Show You
Every AP GUI has configuration knobs that silently change 802.11 protocol behaviour. The GUI labels describe what the setting is called. It never explains what it does to the frames on air, when to change it, or what breaks when you get it wrong. This page does.
I have diagnosed the same configuration mistake across Cisco, Aruba, Juniper Mist, and FortiGate deployments. The GUI labels differ. The protocol consequences are identical.
Short Guard Interval (SGI)
The Guard Interval (GI) is a cyclic prefix prepended to each OFDM symbol to absorb multipath echoes. Standard GI = 800 ns. Short GI = 400 ns. Enabling Short GI reduces the symbol period from 4.0 µs to 3.6 µs - an 11% throughput improvement.
Indoor office environment with low multipath (delay spread < 400 ns). Short range. Clean RF environment with high SNR.
Warehouse with metal racking (delay spread 200-600 ns). Outdoor environments. Any environment where multipath echoes arrive more than 400 ns after the direct signal.
Enabling Short GI in a high-delay-spread environment causes inter-symbol interference (ISI) - the multipath echo from symbol N contaminates symbol N+1. PHY errors increase. The AP rate-adapts clients down to compensate. Net result: throughput is lower with Short GI enabled than with it disabled.
802.11n HT Capabilities IE: SGI-20 (bit 5), SGI-40 (bit 6). Negotiated per-association. 802.11ac/ax: separate bits in VHT/HE Capabilities. Short GI reduces symbol period from 4.0 µs to 3.6 µs - the overhead drops from 20% to 11%.
radiotap.he.data_5.gi == 0 // Short GI active on HE frame
radiotap.mcs.gi == 1 // Short GI on HT frame Band Steering / Client Steering
Band steering encourages dual-band (2.4/5 GHz) or tri-band (2.4/5/6 GHz) clients to connect to the higher band. Mechanism: AP temporarily suppresses Probe Responses to the client on 2.4 GHz while answering normally on 5 GHz. Or: AP sends a BSS Transition Management (BTM) Request (802.11v) pointing the client to a 5/6 GHz BSSID.
Dense deployments where 2.4 GHz is congested. Mixed 2.4/5 GHz client environments. Most enterprise deployments.
IoT devices, legacy devices, and medical equipment that are 2.4 GHz only. Probe suppression breaks these devices permanently - they never receive a Probe Response and cannot associate at all.
Aggressive band steering via probe suppression causes "phantom" association failures that appear in no log. The client sends a Probe Request on 2.4 GHz, receives no response, and either retries indefinitely or gives up. The AP log shows nothing because the AP intentionally suppressed the response. Only visible in PCAP: Probe Request present, Probe Response absent for the affected client.
802.11v BTM Request (Action Frame, Category 10, Action 7) with a Preferred Candidate List pointing to the 5/6 GHz BSSID. Preferred over probe suppression because it is transparent - the client receives a response and can act on it. Client must support 802.11v (Extended Capabilities bit 19) for BTM to work.
wlan_mgt.fixed.action_code == 7 && wlan_mgt.fixed.category_code == 10
wlan.fc.type_subtype == 0x04 && !wlan.fc.type_subtype == 0x05 // Probe Req with no Response Disable Low Data Rates / Basic Rate Set
The Basic Rate Set defines which rates are mandatory for all clients in the BSS. A client that cannot support any basic rate cannot associate. Removing 1, 2, 5.5, and 11 Mbps (802.11b CCK rates) from the basic rate set prevents 802.11b-only clients from joining. It also stops the AP from triggering ERP protection mode for the entire BSS.
Pure 802.11n/ac/ax/be environments. 5 GHz and 6 GHz SSIDs (802.11b is 2.4 GHz only). High-density deployments where beacon overhead matters.
Any deployment with 802.11b legacy devices (old barcode scanners, industrial sensors, legacy printers). Setting minimum rate too high locks out these devices permanently.
Every Beacon, Probe Response, and management frame is transmitted at the lowest mandatory basic rate. If 1 Mbps is in the basic rate set, management frames transmit at 1 Mbps - consuming 6x more airtime than at 6 Mbps. Removing 1/2 Mbps from the basic rate set alone reduces management frame overhead by 40-60% in high-density deployments. Additionally: any 802.11b client that associates triggers ERP protection mode, adding CTS-to-self overhead to every OFDM frame and cutting effective throughput by ~50%.
Supported Rates IE (Element ID 1): bit 7 of each rate byte = mandatory (basic). Extended Supported Rates IE (Element ID 50) for additional rates. ERP IE (Element ID 42): NonERP_Present bit set when a non-ERP STA is associated, triggering protection mode.
wlan.tag.number == 1 // Supported Rates IE
wlan.tag.number == 42 // ERP IE - check NonERP_Present and UseProtection bits
wlan.fc.type_subtype == 0x1c && radiotap.datarate <= 22 // CTS-to-self at CCK rate (protection mode active) BSS Color
BSS Color is a 6-bit field (values 1-63) in the HE-SIG-A preamble field of every 802.11ax/be frame. It identifies which BSS the frame belongs to. An AP receiving a frame with a different BSS Color can apply a higher CCA threshold (OBSS_PD - Overlapping BSS Packet Detect) and potentially transmit simultaneously instead of deferring. This is Spatial Reuse.
Always, on any 802.11ax/be deployment. BSS Color should never be disabled unless a collision is actively causing problems.
After a BSS Color Collision event (two overlapping APs assigned the same color), the AP temporarily disables BSS Color and broadcasts a BSS Color Change Announcement. The AP should automatically assign a new color after the NOP (Non-Occupancy Period).
With BSS Color disabled: every overlapping AP's frames are treated as same-BSS - the receiving STA must defer as if it were a collision. In a dense deployment with 10 overlapping BSSes, this causes unnecessary deferrals on every client at all times. BSS Color collision (two APs with the same color value) has the same effect and is the most common misconfiguration in dense Wi-Fi 6E deployments.
HE Operation IE (Element ID 255, Extension 36): BSS Color Info field. Bits 0-5 = color value. Bit 6 = BSS Color Disabled. Bit 7 = Partial BSS Color. BSS Color Change Announcement IE signals an imminent color change to associated clients.
wlan_mgt.he.operation.bss_color // Current BSS Color value
wlan_mgt.he.operation.bss_color_disabled == 1 // BSS Color currently off
wlan.tag.number == 255 && wlan_mgt.ext_tag.number == 42 // Color Change Announcement Minimum RSSI Threshold / Client Kick
When a client's RSSI drops below the configured threshold, the AP either: sends a BSS Transition Management (BTM) Request with Disassociation Imminent flag (soft steering), or forcibly deauthenticates the client (hard kick) with Reason Code 3. The intent: force "sticky clients" - devices that hold onto a weak AP signal rather than roaming to a stronger one.
Dense deployments where sticky clients degrade throughput for everyone on the AP. VoIP/video deployments where roaming latency matters.
Single-AP deployments. Environments with isolated devices that must stay associated even at low RSSI (IoT sensors at the edge of coverage). Setting threshold too aggressively causes constant disconnects for devices at the coverage edge.
Hard kick (deauthentication) without PMF enabled is spoofable - any device can send a forged Deauth with the AP's BSSID. More importantly: hard kick drops the client entirely. The client must restart the full association sequence from scratch - probe, auth, assoc, EAPOL - adding 200-500ms of reconnect time. BTM with Disassociation Imminent is always preferable: the client gets a target AP suggestion and executes a reassociation (roam) rather than a full reconnect.
BTM Request: Action Frame Category 10, Action 7. Disassociation Imminent bit (bit 2) sets a timer after which the AP will deauthenticate if the client does not roam. BSS Termination Included bit optionally adds termination timestamp. Deauthentication: Reason Code 3 (leaving BSS) is the standard hard kick. With PMF: Deauth is encrypted under PTK.
wlan_mgt.fixed.action_code == 7 && wlan_mgt.fixed.category_code == 10 // BTM Request (soft steer)
wlan.fc.type_subtype == 0x0c && wlan.fixed.reason_code == 3 // Deauth reason 3 (AP kicked client) RTS Threshold
The RTS Threshold (dot11RTSThreshold) sets the MPDU size above which the STA sends an RTS frame before the data frame. The AP responds with CTS, which sets NAV (virtual carrier sense) on all devices that can hear the CTS - including hidden nodes that cannot hear the original transmitter. Default: 2347 bytes (effectively disabled). Enabling: 500-750 bytes in dense deployments with hidden node problems.
High-density deployments with confirmed hidden node collisions (high retransmissions at strong RSSI, distributed across multiple clients). Deployments with physical obstructions creating hidden node conditions.
Default disabled is correct for most deployments. Every RTS/CTS exchange adds ~110 µs overhead. For small frames (most VoIP, DNS, acknowledgements), this overhead exceeds the benefit. Never set to 0 - this sends RTS for every single frame including 20-byte ACKs.
RTS/CTS adds overhead per frame: DIFS + RTS + SIFS + CTS + SIFS before every data frame. For large file transfers, this overhead is a small fraction of the frame airtime. For small frames, it doubles or triples the airtime required. Setting threshold to 0 in a network carrying mostly small frames can reduce effective throughput by 40-60%.
RTS frame (FC 0x1B): 20 bytes. FC, Duration, RA (AP), TA (STA), FCS. Duration field covers DATA+SIFS+ACK - sets NAV on all overhearing STAs. CTS (FC 0x1C): 14 bytes. Duration = RTS Duration minus SIFS minus CTS time. Hidden node C hears CTS, sets NAV, stays silent for the exchange.
wlan.fc.type_subtype == 0x1b // RTS frames
wlan.fc.type_subtype == 0x1c // CTS frames
wlan.duration > 1000 // Duration > 1ms - RTS protection or large TXOP in progress Proxy ARP
Proxy ARP (802.11v WNM feature) causes the AP to intercept ARP Requests from the wired side and respond on behalf of associated clients using the client's last-known MAC address. Without Proxy ARP, an ARP Request for a recently-associated client is broadcast on the WLAN - either going unanswered during the ARP dead window, or consuming airtime as a broadcast on the wireless medium.
Always. There is no downside to Proxy ARP in an infrastructure BSS. It eliminates the ARP dead window, reduces broadcast traffic on the WLAN, and has zero impact on clients.
Debugging ARP behaviour specifically - you may want to see the raw ARP exchange. Otherwise always on.
Without Proxy ARP: ARP Requests from the gateway are broadcast on the WLAN during the dead window after association. Client may not respond in time (GARP race condition). Gateway has no MAC entry. First N packets from gateway to client drop silently. Android marks network "no internet" and routes via LTE. With Proxy ARP: AP answers immediately, dead window eliminated, broadcast storm on WLAN from ARP reduced.
Defined in IEEE 802.11v (WNM). AP maintains a local ARP cache of associated STA IP-to-MAC mappings (populated from DHCP snooping and data frame source addresses). AP responds to ARP Requests on the wired DS with the client's MAC address. Client never sees the ARP Request.
arp.opcode == 1 && arp.src.proto_ipv4 == arp.dst.proto_ipv4 // GARP from client (STA announcing itself)
arp.opcode == 2 // ARP Replies - includes Proxy ARP responses from AP These settings exist in every enterprise AP platform under different labels. The FortiAP GUI says "Short Guard Interval." The Cisco GUI says "Short GI." The Aruba GUI says "Short Guard Interval." The 802.11 standard calls it the Guard Interval. The protocol consequence is identical across all three. When troubleshooting, use the PCAP - not the GUI - to verify what is actually configured.