How many address fields does an 802.11 header contain?
If you’ve ever peeked at a Wi‑Fi packet in Wireshark and seen a string of “addr1”, “addr2”, “addr3”, you’ve probably wondered why there are so many. In real terms, the answer isn’t just “because the spec likes to be fancy. ” It’s a practical solution to a problem that’s been around since the first wireless LANs tried to mimic Ethernet’s simple two‑address model.
In the next few minutes we’ll walk through the whole story—what those fields actually are, why they exist, and how you can read them without a PhD in networking. Because of that, by the end you’ll be able to look at any 802. 11 frame and instantly know which address is the source, which is the destination, and why a fourth field sometimes shows up Simple, but easy to overlook..
What Is an 802.11 Header?
At its core, an 802.11 header is the “envelope” that rides on top of the raw radio bits. Because of that, it tells the receiver how to treat the payload, which device sent it, and where it’s headed. Think of it like the front of a postcard: the post office needs a return address, a destination, and sometimes a special note about how to handle the mail And that's really what it comes down to..
In practice the header is a series of binary fields that get parsed by the NIC firmware. Unlike Ethernet, which only needs a source and a destination address, 802.On top of that, 11 can contain up to four address fields, depending on the frame type and the network topology (infrastructure vs. Worth adding: the most visible parts are the address fields—the bits that hold MAC addresses. ad‑hoc, QoS, etc.) Still holds up..
The Basic Layout
A “plain” 802.11 MAC header starts with:
- Frame Control (2 bytes) – tells you the type/subtype, flags, and whether more address fields follow.
- Duration/ID (2 bytes) – timing info for the medium.
- Address 1 (6 bytes) – always present.
- Address 2 (6 bytes) – always present.
- Address 3 (6 bytes) – present in most frames.
- Sequence Control (2 bytes) – packet number and fragment info.
If the Frame Control’s To DS and From DS bits are set in a particular way, a fourth address (Address 4) appears right after the Sequence Control field Which is the point..
That’s the skeleton. The real question is: when do you get three addresses, when do you get four, and why?
Why It Matters / Why People Care
Most of us think of Wi‑Fi as a black box that just “works.” But when you start troubleshooting dropped packets, setting up a mesh network, or developing a custom driver, those address fields become the bread and butter of your analysis.
Basically where a lot of people lose the thread.
- Security audits – Knowing which MAC is really the source helps you spot rogue APs that try to masquerade as legitimate infrastructure.
- Performance tuning – QoS (Quality of Service) frames use extra address fields to indicate traffic categories. Miss those and you’ll misinterpret bandwidth usage.
- Protocol development – If you ever write a packet injector, you need to get the address order right or the frame will be dropped on the floor.
In short, misunderstanding the address layout can lead to false conclusions, wasted debugging time, and—worst of all—security blind spots Most people skip this — try not to..
How It Works (or How to Do It)
Let’s break down the address field logic by looking at the four possible combinations of the To DS and From DS bits in the Frame Control field. Those two bits decide whether the frame is heading to the Distribution System (the wired backbone) or from it.
1. Both Bits = 0 (Ad‑hoc / IBSS)
| Field | Meaning |
|---|---|
| Address 1 | Destination MAC (the peer you’re talking to) |
| Address 2 | Source MAC (your own NIC) |
| Address 3 | BSSID (the network identifier) |
| Address 4 | Not present |
It's the simplest case. Imagine two laptops talking directly; there’s no AP in the middle, so the BSSID just identifies the ad‑hoc network itself.
2. To DS = 1, From DS = 0 (Station → AP)
| Field | Meaning |
|---|---|
| Address 1 | BSSID (the AP’s MAC) |
| Address 2 | Source MAC (the client) |
| Address 3 | Destination MAC (the final target on the wired LAN) |
| Address 4 | Not present |
Here the client is sending a frame to the Distribution System. The AP will strip the 802.11 header, replace it with an Ethernet header, and forward the packet onward It's one of those things that adds up..
3. To DS = 0, From DS = 1 (AP → Station)
| Field | Meaning |
|---|---|
| Address 1 | Destination MAC (the client) |
| Address 2 | BSSID (the AP’s MAC) |
| Address 3 | Source MAC (the original sender on the wired side) |
| Address 4 | Not present |
Honestly, this part trips people up more than it should.
Now the AP is pulling a packet from the wired side and delivering it to a client. Notice how the BSSID moves to Address 2 – the AP is acting as the “middleman” for both directions.
4. Both Bits = 1 (Wireless Distribution System – WDS)
| Field | Meaning |
|---|---|
| Address 1 | Destination MAC (next hop AP) |
| Address 2 | Source MAC (previous hop AP) |
| Address 3 | BSSID (original network’s identifier) |
| Address 4 | Final destination MAC (the ultimate client) |
WDS is the only scenario where you actually see a fourth address. It’s used when two APs relay traffic for each other without a wired backbone—think of a “wireless bridge” setup. The extra field lets the frame keep track of the ultimate endpoint while hopping across multiple APs.
Putting It All Together
In code, you often see something like:
if (toDS == 0 && fromDS == 0) {
// use addr1 as dst, addr2 as src, addr3 as bssid
} else if (toDS == 1 && fromDS == 0) {
// addr1 = bssid, addr2 = src, addr3 = dst
} // …and so on
The logic is straightforward once you internalize the “to‑DS / from‑DS” matrix. Which means the key takeaway: **the number of address fields is dictated by those two bits, not by the frame type alone. ** Management frames, data frames, and control frames all follow the same address rules; they just differ in what the payload contains.
Common Mistakes / What Most People Get Wrong
-
Assuming Address 1 is always the destination.
In the “Station → AP” case, Address 1 actually holds the AP’s BSSID, not the final destination on the LAN. That’s why Wireshark labels it “Receiver Address” rather than “Destination.” -
Forgetting Address 4 exists.
Many tutorials stop at three addresses and never mention WDS. If you ever capture traffic on a mesh network, you’ll see the fourth field and wonder why Wireshark calls it “RA” (Receiver Address) again Small thing, real impact.. -
Mixing up BSSID and MAC of the AP.
In most home routers the BSSID is the AP’s MAC, but in larger deployments the BSSID can be a virtual MAC (e.g., for multiple SSIDs on the same hardware). Treat them as separate concepts. -
Ignoring the impact of QoS data frames.
QoS adds a “QoS Control” field after the Sequence Control, but it does not add extra address fields. Yet some people think “more fields = more addresses,” which isn’t true. -
Treating the header as static length.
Because the presence of Address 4 (and optional HT/VHT fields) changes the header size, you can’t just assume a fixed offset for the payload. That’s a classic source of off‑by‑one bugs in packet parsers.
Practical Tips / What Actually Works
- Use a packet sniffer that shows field names. Wireshark’s “802.11” view labels each address with its role (RA, TA, DA, SA). That visual cue saves you from having to decode the DS bits manually.
- When writing a parser, read the Frame Control first. Extract the To DS and From DS bits before you decide how many address fields to read. A simple bitmask (
fc & 0x0300) does the trick. - Validate the BSSID against the AP’s MAC. If you’re building a captive‑portal detector, compare the BSSID you see in Address 1 or 2 with the MAC you get from the AP’s beacon frames. Mismatches often signal a rogue AP.
- Don’t forget about “null data” frames. They’re used for power‑save signaling and contain only three addresses, even though they’re technically data frames. Ignoring them can skew power‑usage statistics.
- If you see a fourth address, double‑check the network topology. It’s almost always a WDS bridge or a mesh link. In a typical home setup you should never see Address 4—if you do, you’re probably looking at a mis‑configured repeater.
FAQ
Q: Can a control frame have address fields?
A: Yes, most control frames (like RTS/CTS) include two addresses—one for the receiver and one for the transmitter. They never use the third or fourth address slots Took long enough..
Q: Do IPv6 packets change the number of address fields?
A: No. The MAC‑layer header is agnostic to the IP version. Whether the payload is IPv4, IPv6, or something else, the address field count stays the same.
Q: How does 802.11ax (Wi‑Fi 6) affect the header?
A: 802.11ax adds optional fields (HE Control, HE SIG) after the standard MAC header, but the address field count and placement remain unchanged.
Q: Is the BSSID always the same as the AP’s MAC address?
A: In simple setups, yes. In enterprise or multi‑SSID environments the BSSID can be a virtual MAC, so don’t assume they’re identical without checking the beacon frames Simple, but easy to overlook..
Q: What happens if the To DS/From DS bits are corrupted?
A: The receiver will likely discard the frame as malformed because it can’t correctly map the addresses. Corruption of those bits is a common sign of interference or a faulty NIC.
That’s the whole picture. The 802.11 header can hold three or four MAC addresses, and which ones appear depends entirely on the To DS and From DS flags. Knowing the rule‑book lets you read Wi‑Fi traffic like a pro, spot configuration errors, and avoid the pitfalls that trip up most packet‑sniffing tutorials.
Next time you open Wireshark and see a line of “addr1…addr4,” you’ll know exactly why each one is there—and what it means for the devices talking over the air. Happy sniffing!
And while you're at it, don’t underestimate the value of context. A single frame tells a story—but only when you know the scene. Which means is the device in power-save mode? Is the network using 802.11k/v/r for seamless handoffs? Is it roaming between APs? Now, these factors influence frame timing, content, and even the presence of certain control frames like PS-Poll or BlockAck. Correlate your header analysis with timing deltas and traffic patterns to uncover behaviors hidden in plain sight.
Not the most exciting part, but easily the most useful That's the part that actually makes a difference..
Take this case: a stream of null data frames with identical source and BSSID, spaced precisely at the beacon interval, isn’t just noise—it’s a device silently staying awake without transmitting data. That’s the fingerprint of a smart home sensor polling for commands. Conversely, a sudden spike in QoS Data frames with Address 4 might indicate a mesh node is relaying traffic for a client stuck in a dead zone.
Modern tools like tshark or custom Python scripts using Scapy can automate this detection. Write filters for wlan.But fc. On the flip side, type_subtype == 0x08 to catch beacon anomalies, or wlan. addr4 exists to flag non-standard topologies. Combine this with signal strength trends over time, and you’ve moved from passive observation to active network diagnostics.
Remember: Wi-Fi isn’t just about connectivity—it’s about communication protocols layered atop physical radio waves. On the flip side, every bit in the header exists because someone, somewhere, needed to solve a real-world problem: routing traffic through bridges, preserving battery life, or securing multi-SSID deployments. Understanding the “why” behind the structure turns you from a packet reader into a wireless architect Worth keeping that in mind..
So next time you see a frame, don’t just decode it—interpret it. The airwaves are whispering. Listen closely.