The Story That Explains Why Wireless Needs Its Own Frame Format
Wi-Fi is a conference call. Everyone within radio range shares the same "line" (the air). Anyone can hear everyone else, two people talking at once turns into noise, and a phone that joins late needs someone to state their name before speaking. Because of this, a Wi-Fi frame has to carry information a wired Ethernet frame never needs: who is allowed to talk next, whether the network is encrypted, whether this device is temporarily napping to save battery, and up to four addresses instead of two.
That extra bookkeeping is why the 802.11 MAC frame — the wireless frame format defined by the IEEE 802.11 standard — looks so much more complex than a simple Ethernet frame.
Every device that has ever connected to a Wi-Fi router — laptops, phones, smart TVs — is constantly exchanging these frames, usually dozens of times a second, even when no one is actively browsing. This tutorial breaks down the three frame categories, the header fields inside every frame, and shows real incidents where understanding this structure mattered.
A wireless frame is not just "data with an address on it." It is a small control document. Roughly a third of every frame's header is dedicated purely to managing a shared, invisible, and unreliable medium — the radio spectrum — rather than to the actual message being sent.
Wired vs. Wireless — Why CSMA/CA Changes Everything
Ethernet uses CSMA/CD (Collision Detection): a device can listen and transmit at the same time, so it notices a collision the instant it happens. Radios cannot do this — a transmitting antenna drowns out its own receiver. Wi-Fi is forced to use CSMA/CA (Collision Avoidance): every device must reserve the airtime in advance and hope nobody else reserved the same slot.
| Property | Wired Ethernet (802.3) | Wireless Wi-Fi (802.11) |
|---|---|---|
| Medium | Shielded copper / fibre | Shared open-air radio spectrum |
| Collision handling | CSMA/CD — detect while sending | CSMA/CA — reserve before sending |
| Addresses in header | 2 (source, destination) | Up to 4 (STA, AP, BSSID, mesh relay) |
| Acknowledgement | Handled by upper layers (TCP) | Built into the MAC layer — every unicast frame is ACKed |
| Frame categories | Essentially one (data) | Three: Management, Control, Data |
| Security risk surface | Requires physical cable access | Anyone within radio range can inject/spoof frames |
The Three Frame Categories
Every single frame that a Wi-Fi radio sends belongs to exactly one of three categories, identified by 2 bits in the header called the Type field.
Anatomy of the Generic 802.11 MAC Frame
Regardless of category, every wireless frame shares the same outer skeleton. Not every field is present in every frame type — Address 4 and the QoS Control field, for example, only appear in specific situations explained in Section 08.
| Field | Size | Purpose |
|---|---|---|
| Frame Control | 2 bytes | Identifies frame type/subtype and 8 control flags (see Section 05) |
| Duration / ID | 2 bytes | Microseconds the channel is reserved for (NAV) — or an association ID in some control frames |
| Address 1 | 6 bytes | Receiver address — the immediate radio recipient |
| Address 2 | 6 bytes | Transmitter address — the immediate radio sender |
| Address 3 | 6 bytes | Original source or final destination, depending on ToDS/FromDS (Section 09) |
| Sequence Control | 2 bytes | Sequence number + fragment number, used to detect duplicates and reassemble fragments |
| Address 4 | 6 bytes | Present only in wireless-distribution-system (AP-to-AP) traffic |
| QoS Control | 2 bytes | Present only in QoS data frames — priority level, traffic class |
| Frame Body | 0–7951 bytes | The actual payload (management info elements, or upper-layer data) |
| FCS | 4 bytes | Frame Check Sequence — CRC-32 checksum for error detection |
Control frames are stripped down — many carry only Frame Control, Duration, one or two addresses, and the FCS. Management and Data frames are the ones that carry a full Frame Body. If you see a very short frame in a packet capture, it's almost certainly Control.
Inside the Frame Control Field — Bit by Bit
The Frame Control field is only 2 bytes (16 bits) but it is the busiest part of the header — it single-handedly tells the receiving radio what kind of frame this is and how to handle it.
| Bits | Sub-field | Meaning |
|---|---|---|
| 0–1 | Protocol Version | Always 00 for current 802.11 revisions |
| 2–3 | Type | 00 Management · 01 Control · 10 Data |
| 4–7 | Subtype | Identifies the exact frame — Beacon, RTS, ACK, QoS Data, etc. (Sections 06–08) |
| 8 | To DS | 1 if this frame is headed toward the Distribution System (i.e. to the AP) |
| 9 | From DS | 1 if this frame is coming from the Distribution System (i.e. from the AP) |
| 10 | More Fragments | 1 if more fragments of this MSDU follow |
| 11 | Retry | 1 if this is a retransmission of a previously sent frame |
| 12 | Power Management | 1 if the sending station will enter low-power sleep mode after this frame |
| 13 | More Data | Set by an AP to tell a sleeping station that buffered frames are waiting |
| 14 | Protected Frame | 1 if the frame body is encrypted (WEP/WPA/WPA2/WPA3) |
| 15 | Order / +HTC | Strict ordering requested, or presence of an HT Control field |
Animated Diagram — The CSMA/CA Handshake in Real Time
Watch how a station (STA) reserves airtime before it even sends data. Every other device that hears the RTS or CTS frame sets its NAV (Network Allocation Vector) — a countdown timer — and stays silent until the exchange finishes.
Management Frame Subtypes — Building the Connection
Control Frame Subtypes — Traffic Cops of the Airwaves
Data Frame Subtypes & the ToDS/FromDS Address Puzzle
Data frames carry your actual traffic, but which of the header's addresses means "source" and which means "destination" changes depending on the ToDS and FromDS bits from Section 05. This is the single most misunderstood part of the 802.11 header for people used to Ethernet's simple two-address model.
| To DS | From DS | Scenario | Addr 1 | Addr 2 | Addr 3 |
|---|---|---|---|---|---|
| 0 | 0 | Station → Station (ad-hoc / IBSS) | Destination | Source | BSSID |
| 1 | 0 | Station → AP (typical upload) | BSSID | Source | Destination |
| 0 | 1 | AP → Station (typical download) | Destination | BSSID | Source |
| 1 | 1 | AP → AP (wireless bridge, needs Addr 4) | Receiver AP | Transmitter AP | Final Destination |
In the two most common cases — your phone talking to your home router — the BSSID (the AP's own radio address) occupies a slot that isn't "source" or "destination" at all. Analysts new to Wireshark often misread Addr 3 as the final destination in every frame, when it only means that under specific ToDS/FromDS combinations.
Practical Example — Reading Real Frames in Wireshark
You don't need Python to inspect wireless frames — a $30 USB Wi-Fi adapter that supports "monitor mode" plus Wireshark is enough to watch every field discussed above in real traffic.
Capture Filter — Isolate Management Frames Only
# Wireshark display filter
wlan.fc.type == 0
# Just Beacon frames (type 0, subtype 8)
wlan.fc.type_subtype == 0x08
# Just Deauthentication frames — useful for spotting an attack
wlan.fc.type_subtype == 0x0c
Put a compatible adapter into monitor mode, open Wireshark, and apply
wlan.fc.type_subtype == 0x08. You will see every network broadcasting its
name roughly ten times a second — this is exactly the frame described in Section 07.
Real-World Cases — When Frame Types Made the News
Coverage at the time noted the vulnerability affected essentially every Wi-Fi device on Earth, since the flaw lived in the standard's handshake logic rather than any single vendor's product, prompting an emergency, industry-wide patch effort across operating systems, routers, and chipsets within weeks.
The FCC's enforcement chief stated plainly that consumers should be able to use the data plans they paid for without a third party silently kicking their devices off the air. The case became the reason the FCC later issued formal guidance clarifying that deauthentication frames may not be weaponised to block lawful personal hotspots, regardless of the equipment's original security purpose.
Both incidents exploited the same underlying weakness: Management frames were, for years, sent unauthenticated and unencrypted by design, so a network could be discovered before a device had proven it belonged. WPA3's Protected Management Frames (PMF) requirement exists specifically to close this gap for modern devices.