Techzone/WiFi Frame Reserved Fields

WiFi Frame Reserved Fields

4 min readArticle

Reserved fields in 802.11 frames are bits or bytes that the current standard explicitly defines as "reserved" — meaning they must be set to zero by transmitters and ignored by receivers. They exist to allow future protocol extensions without breaking backward compatibility.

Where Reserved Fields Appear

Frame Control Field (2 bytes)

shell 
Bits: [ Protocol Version (2) ][ Type (2) ][ Subtype (4) ]
      [ To DS ][ From DS ][ More Frag ][ Retry ][ Power Mgmt ]
      [ More Data ][ Protected Frame ][ +HTC/Order ]
  • Bits 0-1 (Protocol Version): Currently always 00. Values 01, 10, 11 are reserved for future protocol versions.
  • Some subtype bits in control frames are reserved — e.g., subtype 0101 through 0111 in control frames are reserved.

Duration/ID Field

  • In certain frame types the top bits of the Duration/ID field are reserved.

Sequence Control Field (2 bytes)

  • Fragment Number (bits 0-3): Values above 0 reserved for non-fragmented frames.

HT Control Field (4 bytes, 802.11n+)

  • Bits 17-29 are explicitly reserved (set to 0). That's 13 reserved bits per HT Control field.

Frame Body Reserved Bits

  • Within Information Elements (IEs), individual bits of the Capability Information field in Beacon/Probe frames contain reserved bits (historically bits 7, 8, 11 were reserved before features were defined).
  • RSN (WPA2) Information Element has reserved bits in pairwise cipher suite and AKM suite selectors.

Why Reserved Fields Matter for Security

1. Covert Channels

Reserved bits that must be set to zero by standard devices are always zero in legitimate traffic. An attacker can set them to non-zero values to encode hidden data:

shell 
13 reserved bits in HT Control = 1.6 bytes per frame
1000 frames/second × 1.6 bytes = ~1.6 KB/s covert channel

This has been demonstrated in research — see "80211 Covert Channel" papers. Detection requires a WIDS that actively checks reserved bit values (most don't by default).

2. Device Fingerprinting

Different chipsets and drivers handle reserved bits differently:

  • Some drivers zero reserved bits correctly
  • Some drivers copy reserved bits from received frames into replies (leaking sender's bits)
  • Some firmware sets specific reserved bits due to implementation bugs

A fingerprinting scan can determine chipset/driver by analyzing which reserved bits appear non-zero and in which frame types.

bash 
# Capture traffic and analyze with tshark for non-zero reserved bits
tshark -r capture.pcap -T fields \
  -e wlan.fc.type \
  -e wlan.fc.subtype \
  -e wlan.fc.ds \
  -e frame.len \
  | grep -v "^0\s"

# Specifically look for protocol version != 0 in Frame Control
# (should always be 0 in valid frames)
tshark -r capture.pcap -Y "wlan.fc.version != 0"

3. Driver/Stack DoS via Reserved Bit Abuse

Some WiFi drivers fail to properly ignore reserved fields and crash or misbehave when they receive frames with unexpected reserved bit values. Historical CVEs include:

  • CVE-2006-6332 — Broadcom bcm43xx driver crash on malformed frame
  • Various "fuzzing" CVEs from libwifi/wpa_supplicant that were triggered by malformed IE reserved fields

Attack approach: fuzz the reserved fields systematically:

python 
from scapy.all import *
from scapy.layers.dot11 import *

# Craft a probe request with non-zero protocol version (reserved)
# FC byte 0: protocol version bits = 01 (reserved, normally 00)
malformed = RadioTap() / \
    Dot11(proto=1) / \  # proto=1 sets reserved protocol version bits
    Dot11Elt(ID="SSID", info="TestNetwork")
sendp(malformed, iface="wlan0mon", count=100)

4. IDS/WIDS Evasion

Some intrusion detection signatures match on specific frame structures. By setting reserved bits in a way that confuses the signature engine while still being valid enough for the target to process, an attacker can evade detection. This is a form of protocol-level IDS evasion analogous to TCP/IP fragmentation attacks.

Detection and Monitoring

bash 
# Wireshark filter: frames with non-zero protocol version (always reserved)
wlan.fc.version != 0

# Script to check reserved bits systematically
tshark -r capture.pcap -T json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for pkt in data:
    fc = pkt.get('_source',{}).get('layers',{}).get('wlan',{})
    ver = fc.get('wlan.fc.version','0')
    if ver != '0':
        print(f'Non-zero protocol version: {pkt}')
"

Legitimate Uses of Reserved Bits

In practice, reserved bits are sometimes used by vendors for proprietary extensions before they're standardized. For example:

  • Cisco's Compatible Extensions (CCX) used some reserved IE fields for proprietary features
  • Early 802.11e QoS features used bits that were "reserved" in earlier standard versions
  • 802.11ax (Wi-Fi 6) redefined bits that were reserved in 802.11n/ac

This means non-zero reserved bits don't always indicate an attack — but they do indicate either a non-standard implementation, a future protocol version, or something worth investigating.

Reference

techzonesite.comUnlock Your IT Potential