// reference · vendor feature map
Wi-Fi Vendor Feature Reference
Every vendor has a branded name for what is usually a standard 802.11 feature - or a proprietary extension with no standard equivalent.
This page maps the marketing name to the IEEE clause, tells you what it looks like in a PCAP, and flags what is truly proprietary.
— Shankar K., Wi-Fi engineer, Irving TX · Building WiFi Analyser
CSCO
Cisco
Platforms: Catalyst (IOS-XE) · WLC (AireOS) · Catalyst Center · Meraki
Two controller worlds: AireOS (legacy WLC, being phased out) and IOS-XE Catalyst (current). The CLI syntax, CAPWAP behaviour, and feature flags differ. When you open a PCAP and see CAPWAP tunnels, you need to know which world you're in to read the control-plane correctly.
Feature mapping
| Cisco Name | IEEE Standard | PCAP Identification | Notes |
|---|---|---|---|
| CCKM Cisco Centralized Key Management | PROPRIETARY | wlan_mgt.rsn.akms.type == 0 OUI 00:40:96 in RSN AKM suite. Seen in AssocReq RSN IE. Predates 802.11r - fast roam without FT. | Legacy fast roam. Cisco CCX clients only. If you see OUI 00:40:96 in the AKM list, CCKM is in play. Will not coexist with 802.11r cleanly. |
| RRM Radio Resource Management | 802.11h TPC + 802.11k | wlan_mgt.meas_rep Measurement Report action frames (cat=0). RRM neighbor list in Beacon: IE id=70. | Cisco's RRM runs on WLC/Catalyst Center. Power changes visible via TPC Report frames. Channel changes cause a full beacon update - watch for CSA IE. |
| FlexConnect Local switching at AP | PROPRIETARY | No direct 802.11 frame marker. Identify by DHCP source - in FlexConnect local switch mode, DHCP Offer comes from local subnet gateway, not from WLC tunnel. Compare DHCP timing: FlexConnect is faster. | In PCAP: DHCP response timing is the tell. Central switch = DHCP goes through CAPWAP to WLC and back. Local switch = DHCP handled locally, faster first packet. Critical for branch deployments. |
| DTPC Dynamic Transmit Power Control | 802.11h TPC | wlan_mgt.tim.dtim_count TPC Report action frames. Power constraint IE (id=32) in beacons when DTPC active. | Standard 802.11h underneath. Cisco's implementation allows tighter per-AP control via WLC. Power Constraint IE value in beacon tells you the reduction in dBm. |
| Adaptive 802.11r | 802.11r (hybrid) | wlan_mgt.rsn.akms.type == 4 AKM type 4 (FT-PSK) or 3 (FT-EAP) in RSN IE of Beacon + AssocReq. FT Auth frames present. | Cisco's adaptive mode allows non-FT clients and FT clients on the same SSID. In PCAP: FT-capable clients use Reassoc; non-FT clients use full Auth+Assoc. Both visible in the same capture. |
| mDNS Gateway | PROPRIETARY (Layer 3) | Not visible in 802.11 frames. Seen in L3 capture as mDNS (UDP 5353) proxied from AP subnet to client subnet. Requires L3/L4 capture to diagnose. | Cisco solution for mDNS across VLANs (AirPlay, Chromecast, printers). If mDNS devices disappear after a VLAN change, this is usually the culprit. No 802.11 PCAP diagnostic - need L3 capture. |
| CAPWAP Control and Provisioning of WAPs | RFC 5415 | udp.port == 5246 || udp.port == 5247 UDP 5246 = control, 5247 = data. Only visible in wired captures between AP and WLC. 802.11 PCAP won't show this. | The tunnel between AP and WLC. CAPWAP data tunnel wraps the 802.11 frame. When debugging AP join failures, filter UDP 5246 on a wired capture - look for DTLS handshake completion. |
Field note: The most common Cisco PCAP finding I see is CCKM vs 802.11r coexistence failures. Customer has upgraded to 802.11r but kept legacy CCKM SSID - the AKM negotiation in the AssocReq shows both OUIs. Clients pick CCKM and bypass FT entirely. Filter
wlan_mgt.rsn.akms in AssocReq and count which AKM is actually selected.
Key CLI - IOS-XE Catalyst
# Show all clients and their roaming method
show wireless client summary
# Show 802.11r fast transition details per client
show wireless client mac-address <MAC> detail | include FT
# Show RRM channel assignment
show ap auto-rf dot11 5ghz
# Show CAPWAP tunnel state
show ap status | include CAPWAP
show wireless client summary
# Show 802.11r fast transition details per client
show wireless client mac-address <MAC> detail | include FT
# Show RRM channel assignment
show ap auto-rf dot11 5ghz
# Show CAPWAP tunnel state
show ap status | include CAPWAP
ARB
Aruba (HPE)
Platforms: AOS 8 (Mobility Conductor) · AOS 10 (cloud-native) · Aruba Central · Instant AP
AOS 8 vs AOS 10: AOS 8 uses a Mobility Conductor (hardware or virtual) with Mobility Controllers. AOS 10 is controller-less - each AP runs its own control plane. This changes where to look when troubleshooting: in AOS 8, the WLC logs tell the roaming story; in AOS 10, it is all in the AP and Aruba Central.
Feature mapping
| Aruba Name | IEEE Standard | PCAP Identification | Notes |
|---|---|---|---|
| ClientMatch | 802.11v BTM + proprietary layer | wlan_mgt.fixed.action_code == 7 BTM Request action frame (cat=10, action=7). ClientMatch adds load data from Aruba Central - the BTM frame itself is standard but the triggering logic is proprietary. | Looks identical to standard 802.11v BTM in a PCAP. The proprietary part is the AI-driven trigger - Aruba Central aggregates load across APs and triggers BTM based on real-time capacity, not just RSSI. You cannot see this in the 802.11 frame. |
| ARM Adaptive Radio Management | 802.11h + 802.11k | wlan_mgt.meas_rep Same Measurement Report frames as standard 802.11h TPC. Channel changes: CSA IE (id=37) in beacons before switch. | ARM handles channel + power. When ARM triggers a channel change, you will see CSA IE in beacons for the countdown period (typically 10 DTIM intervals), then the channel switch. Count the CSA countdown in the PCAP. |
| AirMatch | 802.11k (data source) + proprietary optimization | Not visible in 802.11 frames. AirMatch runs nightly on Mobility Conductor - you see the result as a channel/power change the next morning. Diagnose via Aruba logs, not PCAP. | Aruba's successor to ARM for large deployments. Collects 802.11k measurement data across all APs overnight, runs global RF optimization, pushes new channel/power plan at a scheduled time. PCAP shows the outcome, not the process. |
| AppRF | PROPRIETARY - L7 DPI | Not visible in 802.11 PCAP. Requires L7 capture (mirrored wired port). Aruba classifies application traffic using DPI - YouTube, Zoom, Teams - and applies per-application QoS policies. | Application-aware QoS. When a client's Zoom call is degraded but the 802.11 PCAP looks clean, check AppRF policy - it may be rate-limiting the application. No 802.11 frame signature. |
| Aruba Fast Roam OKC + 802.11r | 802.11r FT + OKC | wlan_mgt.rsn.akms.type == 4 AKM type 4 (FT-PSK) or 3 (FT-EAP). For OKC: standard PSK AKM (type 2) but PMKID cached - you see Reassoc without a new EAPOL handshake. | Aruba supports both 802.11r and OKC (Opportunistic Key Caching). OKC is the key: client reassociates using a cached PMKID without a new 4-way handshake. In PCAP: Reassoc frames present, no EAPOL M1-M4 = OKC in use. Full EAPOL after Reassoc = 802.11r failed, fell back to full auth. |
| Dynamic Segmentation | PROPRIETARY - tunnelled VLAN | Not visible in 802.11 frames. Requires wired capture on the AP uplink - look for GRE tunnel (protocol 47) between AP and Aruba gateway. | Aruba tunnels client traffic back to a central policy engine regardless of VLAN. Enables per-user policy without VLAN proliferation. If a client's traffic is routed unexpectedly, Dynamic Segmentation policy is the first place to check. |
Field note: ClientMatch is the feature I get asked about most often. Engineers see BTM Request frames in a PCAP and assume 802.11v is the whole story. It is not - the ClientMatch trigger logic lives in Aruba Central and factors in real-time client load across the entire RF domain. The BTM frame is standard. The intelligence is invisible in the PCAP.
Key CLI - AOS 8
# Show client roaming history and method used
show ap association | include <MAC>
# Show ClientMatch decisions for a client
show ap debug client-match client-mac <MAC>
# Show ARM channel + power assignment
show ap arm rf-summary
# Show OKC PMKID cache
show aaa state user <MAC>
show ap association | include <MAC>
# Show ClientMatch decisions for a client
show ap debug client-match client-mac <MAC>
# Show ARM channel + power assignment
show ap arm rf-summary
# Show OKC PMKID cache
show aaa state user <MAC>
RKS
Ruckus (CommScope)
Platforms: SmartZone · Unleashed (controller-less) · Ruckus Cloud · Virtual SmartZone
BeamFlex+ is the differentiator - but it is invisible in a PCAP. Ruckus adaptive antenna technology changes the antenna pattern per packet. You cannot see this in frames. What you can see is the result: unusually consistent RSSI across a roaming session, lower retry rates than expected for a given client position, and fewer retransmissions at the edge of coverage.
Feature mapping
| Ruckus Name | IEEE Standard | PCAP Identification | Notes |
|---|---|---|---|
| BeamFlex+ Adaptive Antenna | PROPRIETARY | Not visible in 802.11 frames. Diagnose by result: compare retry rate and RSSI variance across a roaming session vs equivalent Cisco/Aruba AP at same position. BeamFlex shows lower variance. | Per-packet antenna pattern selection using 4,000+ patterns. The AP picks the best pattern for each frame based on the previous ACK. PCAP shows consistent RSSI - the mechanism is invisible. This is Ruckus's primary hardware differentiator. |
| ChannelFly | 802.11h (channel switch) + proprietary selection | wlan_mgt.csa CSA IE (id=37) in beacons during channel transition. ChannelFly moves channels more aggressively than standard RRM - watch for more frequent CSA announcements. | Ruckus monitors airtime utilization in real time and moves channels when utilization exceeds a threshold. More aggressive than Cisco RRM or Aruba ARM in crowded environments. In PCAP: watch for CSA IE appearing during peak hours - that is ChannelFly responding to congestion. |
| SmartMesh Wireless backhaul | 802.11s (basis) + 4-address | wlan.fc.tods == 1 && wlan.fc.fromds == 1 4-address frames (ToDS=1, FromDS=1). Mesh link frames have both AP addresses visible. Backhaul SSID is hidden but visible in mesh probe exchanges. | Ruckus mesh uses 4-address frames on the backhaul link. In a PCAP, you will see frames with both ToDS and FromDS set - this is the mesh hop. High retry rate on these frames = mesh link quality problem, not client issue. |
| Zero-IT / DPSK Dynamic PSK | PROPRIETARY | wlan_mgt.rsn.akms.type == 2 Standard WPA2-PSK AKM in frames - DPSK is invisible at the 802.11 layer. Each client gets a unique PSK but the 4-way handshake looks identical to shared PSK. | Each onboarded client receives a unique PSK derived from their MAC. The 802.11 PCAP shows standard WPA2-PSK - DPSK is a backend authentication mechanism. If one client's connection is revoked, other clients are unaffected. Cannot be detected from PCAP alone. |
| Band Balancing | 802.11v BTM (optional) | wlan_mgt.fixed.action_code == 7 BTM Request (cat=10, action=7) when steering to 5 GHz. Some Ruckus firmware uses probe suppression instead - no frame visible for that method. | Ruckus uses a combination of probe suppression (2.4 GHz probes ignored for dual-band clients) and BTM. Probe suppression is invisible in PCAP - client appears to self-select 5 GHz. BTM-based steering leaves a visible action frame trail. |
Field note: SmartMesh 4-address frames are the one Ruckus-specific PCAP pattern that engineers consistently misread. They see ToDS=1 and FromDS=1 and assume they have a WDS bridge or a capture error. It is SmartMesh backhaul. Filter
wlan.fc.tods == 1 && wlan.fc.fromds == 1 - if you are seeing this on an SSID that should be client-facing, you have captured the mesh backhaul link by accident.
Key CLI - SmartZone
# Show client roaming event log
get client-event mac <MAC>
# Show mesh topology and link quality
get mesh neighbor all
# Show channel utilization per AP
get ap-stats channel-utilization apname <name>
get client-event mac <MAC>
# Show mesh topology and link quality
get mesh neighbor all
# Show channel utilization per AP
get ap-stats channel-utilization apname <name>
UBI
Ubiquiti
Platforms: UniFi Network (consumer/SMB) · UISP (ISP/outdoor)
Key limitation to know upfront: UniFi has no enterprise-grade RRM. Channel and power assignments are either manual or use a basic scan-based auto-select that runs once at AP adoption. In enterprise deployments, this is where UniFi consistently falls short vs Cisco/Aruba/Ruckus. In a PCAP, you often see this as co-channel interference that proper RRM would have avoided.
Feature mapping
| UniFi Name | IEEE Standard | PCAP Identification | Notes |
|---|---|---|---|
| Fast Roaming | 802.11r FT | wlan_mgt.rsn.akms.type == 4 AKM type 4 (FT-PSK) or 3 (FT-EAP) in Beacon RSN IE. FT Auth frames visible on roam. Available from UniFi firmware 5.x+. | UniFi's 802.11r is a clean standard implementation - no proprietary extension. If Fast Roaming is enabled in UniFi controller, you will see FT AKMs advertised in beacons. If disabled, clients do full Auth+Assoc+EAPOL on every roam. |
| Band Steering | 802.11v BTM + probe suppression | wlan_mgt.fixed.action_code == 7 BTM Request (cat=10, action=7). UniFi also uses 2.4 GHz probe suppression for dual-band clients - those steers are invisible in PCAP. | Works for most clients. Aggressive Band Steering can cause connection issues on 2.4 GHz-only devices if UniFi mistakenly identifies them as dual-band. In PCAP: client sends 2.4 GHz probe, no response, client waits, then retries on 5 GHz - the missing probe response is the tell. |
| Minimum RSSI aka signal cutoff | PROPRIETARY | Not visible in 802.11 frames. Identify by pattern: client sends AssocReq, no AssocResp from AP (AP silently drops). Client retries on a different AP or channel. Compare with normal deauth-based kick. | UniFi's sticky client fix. AP silently ignores probe requests and association requests from clients below the RSSI threshold. No IEEE standard equivalent - just a drop at the AP level. In PCAP: you see client AssocReq with no response. The client then scans and connects to a stronger AP. |
| AI-driven WiFi UniFi Dream Machine | MARKETING | No PCAP signature. Basic channel/power optimization that runs periodically. Not comparable to Cisco RRM, Aruba ARM, or Juniper Mist AI in depth or frequency. | The "AI" label in UniFi refers to a periodic background scan and channel reassignment - not real-time RF optimization. In enterprise deployments: plan channels manually and disable auto-optimize unless the environment is stable. |
| Roam Assist | 802.11v BTM | wlan_mgt.fixed.action_code == 7 BTM Request with BSS Transition Candidate List. UniFi includes candidate APs with RSSI estimates. Check that candidate list actually lists stronger APs - misconfigured Roam Assist sends clients to worse APs. | Standard 802.11v with a candidate list. In PCAP: inspect the BTM Request candidate list IE. If the listed APs have lower RSSI than the current AP, Roam Assist config is wrong. This is a common SMB deployment error. |
Field note: The Minimum RSSI silent drop is the most misdiagnosed UniFi behaviour I encounter. Engineer sees a client repeatedly attempting to connect to one AP with no response, assumes AP hardware fault. It is Minimum RSSI - the AP is healthy but ignoring the client. Filter by client MAC, look for AssocReq with no AssocResp on the same BSSID. Then check the next successful association - client connected to a stronger AP. That is Minimum RSSI working correctly.
Key settings - UniFi Network
# SSH into AP - show client associations and RSSI
iwconfig ath0 | grep -i signal
# Show connected clients with signal strength
cat /proc/net/madwifi/ath0/associated_sta
# Controller API - client events (UniFi Network Application)
GET /api/s/default/stat/event?_sort=-time&within=60
iwconfig ath0 | grep -i signal
# Show connected clients with signal strength
cat /proc/net/madwifi/ath0/associated_sta
# Controller API - client events (UniFi Network Application)
GET /api/s/default/stat/event?_sort=-time&within=60
MIST
Juniper Mist
Platforms: Mist Cloud · Marvis AI · Wired Assurance · WAN Assurance
Cloud-native from day one. Every AP streams telemetry to Mist Cloud in real time - frame-level data, RSSI, client events, roaming decisions. Marvis AI processes this centrally. Most Mist diagnostics happen in the cloud dashboard, not via CLI. When you do open a PCAP from a Mist environment, the 802.11 frames are standard - Mist's intelligence is in the cloud layer above them.
Feature mapping
| Mist Name | IEEE Standard | PCAP Identification | Notes |
|---|---|---|---|
| Marvis AI AI-driven operations | PROPRIETARY - cloud layer | Not visible in 802.11 frames. Marvis ingests telemetry from APs via cloud. The actions it triggers (BTM requests, channel changes) produce standard 802.11 frames - you see the effect, not the cause. | Marvis identifies patterns across thousands of client events - sticky clients, repeat auth failures, DHCP timeouts - and suggests or automates remediation. When Marvis triggers a BTM, the PCAP shows a standard BTM Request. The AI decision that caused it is in the Mist Cloud dashboard. |
| Dynamic Packet Capture | PROPRIETARY - AP feature | Not a PCAP identification target - this IS the PCAP. Mist can trigger packet capture at the AP remotely from the cloud dashboard. Download the .pcap from Mist portal. Useful for reproducing intermittent client issues. | Mist's killer troubleshooting feature. Trigger a capture from the cloud dashboard without SSH to the AP. Captures 802.11 frames at the AP radio and uploads to Mist portal for download. Filters available: by client MAC, frame type, SSID. |
| Mist AI Steering | 802.11v BTM + AI trigger | wlan_mgt.fixed.action_code == 7 Standard BTM Request frame. Mist includes client load, airtime, and predicted RSSI in the steering decision. Frame is standard - intelligence is cloud-side. | Most sophisticated roaming assist in the industry. Mist considers actual airtime utilization, client history, and predicted coverage before issuing BTM. In PCAP: identical to standard BTM. Evaluate quality of steering by comparing RSSI before and after the BTM-triggered roam. |
| Wi-Fi 7 MLO Support | 802.11be MLO | wlan_mgt.ext_tag.number == 107 Multi-Link Element (ext tag 107) in Beacon and AssocReq. Per-STA Profile sub-element lists each link. Parse with WiFi Analyser for eMLSR vs STR classification. | Mist APs (AP45, AP63) support 802.11be MLO. In PCAP: Multi-Link Element present in both Beacon and client AssocReq confirms MLO negotiated. Check per-STA profile for link bands - 5+6 GHz STR is the most common combination in current deployments. |
| SLE (Service Level Expectation) | PROPRIETARY - metrics layer | Not visible in 802.11 frames. SLE aggregates: time-to-connect, roaming latency, throughput, and coverage into per-client SLA scores. Use Mist Cloud dashboard, not PCAP, for SLE diagnostics. | Mist's SLE tracks real user experience: did this client's association take too long? Did their roam exceed 50ms? Is their RSSI below -72 dBm? These metrics come from AP telemetry, not PCAP. When SLE flags a client, then open a PCAP to find the root cause. |
| EVPN-VXLAN Integration | RFC 7348 (VXLAN) + RFC 7432 (EVPN) | Not visible in 802.11 frames. Requires wired capture - look for VXLAN (UDP 4789) between AP and QFX/EX switch. This is the Juniper campus fabric integration. | Mist integrates with Juniper EX/QFX switches for EVPN-VXLAN campus fabric. Client traffic is tunnelled via VXLAN to a central gateway. Relevant when clients get unexpected VLAN assignments after a roam - check EVPN route table, not the AP config. |
Field note: The Dynamic Packet Capture feature is what makes Mist stand out for protocol-level troubleshooting. Most vendors require SSH to the AP to trigger a capture - which means you need network access, AP credentials, and someone physically present if remote access is down. Mist triggers it from the cloud dashboard regardless. When a client has an intermittent issue that never reproduces on demand, set a Mist capture trigger on that client MAC and wait. The PCAP uploads automatically when the event occurs.
Feature comparison - all vendors
Standard implementation = IEEE 802.11 compliant, visible in PCAP with standard filters. Proprietary = vendor-specific, not visible in standard 802.11 PCAP or requires vendor CLI to understand.
| Feature | Cisco | Aruba | Ruckus | Ubiquiti | Juniper Mist | PCAP visible? |
|---|---|---|---|---|---|---|
| Fast roaming | 802.11r + CCKM | 802.11r + OKC | 802.11r | 802.11r | 802.11r | Yes - FT AKM in RSN IE |
| Client steering | 802.11v BTM | 802.11v + ClientMatch AI | 802.11v + probe suppression | 802.11v + probe suppression | 802.11v + Marvis AI | Partial - BTM frame yes, trigger logic no |
| RF optimization | RRM (802.11h/k) | ARM + AirMatch | ChannelFly | Basic scan-only | Marvis AI RRM | Partial - CSA frames visible, logic not |
| Adaptive antenna | None | None | BeamFlex+ | None | None | No - effect visible as low retry rate |
| Packet capture | CLI + Catalyst Center | CLI + Aruba Central | CLI | SSH to AP | Cloud dashboard - no SSH needed | N/A |
| Wi-Fi 7 MLO | Catalyst 9136 (ax+) | Aruba 730 series | R770 series | U7 series | AP45, AP63 | Yes - Multi-Link Element (ext tag 107) |
| Sticky client fix | BTM + coverage hole detection | ClientMatch (load-aware) | BTM + SmartZone events | Minimum RSSI (silent drop) | Marvis SLE + BTM | BTM visible; Minimum RSSI silent |
| Enterprise RRM | Yes | Yes | Yes | No | Yes (AI-driven) | CSA frames visible, decision logic not |
PCAP rule of thumb: If you can see it in a standard 802.11 PCAP, it is based on an IEEE standard. If you need vendor CLI or a cloud dashboard to understand it, it is proprietary. The exceptions are features like BeamFlex+ and Minimum RSSI - proprietary behaviour with visible side-effects in frames, but no direct frame signature.
// companion tool
Identify these patterns automatically
Upload a PCAP to WiFi Analyser and it checks for RSN IE mismatches, FT AKM presence, BTM request flows, 4-address mesh frames, BSS Color collisions, and 60+ other protocol patterns - automatically, in under 15 seconds.
Open WiFi Analyser →