Wi-Fi (IEEE 802.11) shares Ethernet's frame format, but the fact that it rides on the shared medium of radio waves brings in every layer wired networks didn't need to think about — CSMA/CA, half-duplex, L2 retransmission, the 4-way Handshake, WPA generations, DFS, MAC randomization. This article covers the 6-stage connection lifecycle from SSID tap to receiving an IP, the WEP → WPA3 generations of encryption, the 2.4/5/6 GHz bands and channels, what Wi-Fi 6/6E/7 changed, the main L2 attacks of deauth / evil twin / PMKID / WPS, and the post-MAC-randomization era of privacy.
Why wireless is fundamentally different from wired #
Wi-Fi is L2 just like Ethernet, but the spec is complex because it rides on the shared medium of radio waves.
| Aspect | Ethernet (wired) | Wi-Fi (wireless) |
|---|---|---|
| Medium | One pair per link, isolated by switches | One channel shared by everyone nearby |
| Collision detection | Full-duplex, no collisions today | The transmitter's own radio masks reception → cannot be detected |
| Collision avoidance | Not needed | CSMA/CA: "wait until quiet + a random back-off before transmitting" |
| Direction | Full-duplex | Half-duplex (cannot receive while transmitting) |
| Losses | Only on cable faults | Constantly (walls, people, microwaves, neighboring APs) |
| L2 retransmission | None (TCP's job) | Yes — every frame demands an ACK; the MAC layer retransmits if missing |
| Identifier | Physical port | The combination of MAC + BSSID + SSID + channel |
| Security | Physical access assumed | Anyone can sniff the radio → encryption is mandatory |
The design idea "collisions can't be detected, so prevent them" — CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) — is the divergence point from Ethernet's CSMA/CD. Before transmitting, wait for DIFS plus a random back-off; if nothing else is on the air, transmit; if something is, count down again. Every transmitted frame requires an ACK, and if none arrives, the back-off is doubled and the frame is retransmitted (binary exponential backoff).
If A and C both reach the AP but cannot reach each other, they can't see each other in CSMA/CA and will collide. The optional RTS/CTS handshake exists to solve this, but the overhead is large enough that modern high-density AP deployments often leave it off.
All of this is the source of the experiences users feel every day — "Wi-Fi only delivers half to two-thirds of its rated speed", "it gets linearly slower as people arrive", "5 GHz is fast but doesn't reach".
The connection lifecycle — from SSID tap to data #
Behind "I'm on Wi-Fi" lurks a 6-step exchange. It physically completes in under a second.
Hidden SSID just omits the SSID from the Beacon, but the SSID name appears in Probe Requests and leaks from already-connected clients. "Seeing the SSID list" ≠ "trying to connect" — they are just sniffing Beacons.
What's inside the 4-way Handshake #
PTK derivation: PTK = PRF(PMK, ANonce, SNonce, AP MAC, STA MAC) — mixing in random nonces from both sides ensures a different key per session (close to PFS). Even if the PMK is reused, the session key is not. For PSK: PMK = PBKDF2(SSID, passphrase). All four frames are carried via EAPOL (EAP over LAN, EtherType=0x888E).
For WPA2-Enterprise (802.1X), EAP runs in place of Open System (EAP-TLS / PEAP / EAP-TTLS). A RADIUS server is the authentication backend and identifies the individual via certificate (EAP-TLS) or AD password (PEAP-MSCHAPv2). The 4-way Handshake runs after EAP completes.
$ nmcli device wifi list # channel / signal / security
$ sudo iw dev wlan0 scan | grep -E "SSID|signal|Authentication suites"
# detail on the connected AP (channel width / MCS / RSSI)
$ iw dev wlan0 link
Connected to aa:bb:cc:dd:ee:ff (on wlan0)
SSID: MyHome
freq: 5180
signal: -52 dBm
tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2
RX: CCMP / TX: CCMP
$ iw dev wlan0 station dump
# monitor mode (for packet analysis)
$ sudo iw dev wlan0 set monitor controlWPA generations — WEP / WPA / WPA2 / WPA3 #
Because anyone can sniff radio, encryption was mandatory from day one. But "the first method broke, then the next broke, then the next…" has been repeating itself for a quarter century.
| Method | Year | Cipher | Auth | Status |
|---|---|---|---|---|
| WEP | 1997 | RC4 (40 / 104 bit key) | Shared key | Completely dead — broken in minutes (FMS, KoreK, PTW attacks). If found today, disable only |
| WPA (TKIP) | 2003 | RC4 + TKIP key updates | PSK or 802.1X | A stopgap for WEP, deployable as a firmware update on existing hardware. Not recommended today |
| WPA2 (CCMP/AES) | 2004 | AES-CCMP (CCM mode AES-128) | PSK or 802.1X (EAP) | The mainline for 15 years. KRACK (2017) exposed a 4-way replay vulnerability (patched); PMKID attack (2018) made offline PSK cracking easy |
| WPA3 (SAE/GCMP) | 2018 | AES-GCMP-128/256 | SAE (Dragonfly key exchange) | Resistant to offline dictionary attacks / early implementations had Dragonblood (2019) → since fixed / PMF mandatory |
Under WPA2-PSK, PMKID = HMAC(PMK, ...) appears in the AP's Beacon/Association, so capturing a single frame is enough to start offline dictionary attacks on the PSK (hashcat -m 22000). SAE is mathematically designed so the PMK cannot be derived from the on-air information (the dragonfly key exchange over a finite field), so even weak PSKs are protected against dictionary attacks.
PMF (Protected Management Frames, 802.11w) #
A standard that encrypts management frames like Auth / Deauth / Disassoc. Without it, an attacker can disconnect any client by forging a Deauth frame (= Wi-Fi-side DoS, evil twin enabler). PMF is mandatory in WPA3, and optionally enabled in WPA2.
$ nmcli connection show "MyHome" | grep -i security
802-11-wireless-security.key-mgmt: sae
802-11-wireless-security.pmf: required
$ iw dev wlan0 link
RX: CCMP / GCMP ...For new builds: WPA3-Personal (SAE) + mandatory PMF. WPA3/WPA2 transition mode is available for compatibility, but flipping to WPA3-only once all WPA2-only devices are gone is recommended. For enterprise, WPA3-Enterprise + EAP-TLS (certificates) is the best answer. Don't hide the SSID, MAC filtering is effectively useless — both are the classic "felt-secure-but-not-actually-secure" mistakes.
The physical layer — bands and channel widths #
Almost every "Wi-Fi is slow / unstable" complaint is physical-layer congestion. The basics of bands and channels are worth knowing.
| Band | Standards | Range | Notes |
|---|---|---|---|
| 2.4 GHz | 802.11b/g/n | 2401-2483 MHz (Japan ch1-13) | Best range / penetration / only 1, 6, 11 are non-overlapping / heavily interfered with by Bluetooth, microwaves, neighboring APs |
| 5 GHz | 802.11a/n/ac/ax | 5170-5835 MHz (W52/W53/W56) | Supports 80/160 MHz channels / DFS region (52-144) is forced off-channel on weather/maritime radar detection |
| 6 GHz | Wi-Fi 6E / 7 | 5945-7125 MHz (1200 MHz contiguous) | Virtually no congestion (new) / 320 MHz × 3 channels (Wi-Fi 7) / WPA3 required / shortest range |
Channel width vs theoretical throughput #
- 20 MHz — ~150 Mbps (Wi-Fi 5, 1 stream) — most stable but slow
- 80 MHz — ~600 Mbps
- 160 MHz — ~1.2 Gbps
- 320 MHz — ~2.4 Gbps (Wi-Fi 7) — the wider it is, the more congestion area you cover
The 5 GHz DFS (Dynamic Frequency Selection) region (5.25-5.72 GHz, parts of W53/W56) is required to vacate the channel on detection of weather or maritime radar — the AP drops for seconds to minutes while it moves. A common cause of "home Wi-Fi drops sometimes".
MCS and MIMO/MU-MIMO/OFDMA #
MCS (Modulation and Coding Scheme) is "the speed tier for the current SNR". Near the AP, MCS rises and you can pack 4096-QAM (Wi-Fi 7); as you move away, it falls to 256-QAM → 64-QAM → BPSK and finally drops out. "It gets slower as I walk away" is this happening.
- MIMO — multiple antennas for spatial multiplexing. One client, 2 streams → 2× rate (standardized in Wi-Fi 5)
- MU-MIMO (Wi-Fi 5/6) — sends different streams to multiple clients simultaneously
- OFDMA (Wi-Fi 6) — the channel is subdivided along the frequency axis (RU = Resource Unit), letting many small-packet clients be packed in simultaneously. Effective in high-density IoT environments
Wi-Fi 6 / 6E / 7 — what changed #
| Gen | Common name | Standard | Main evolution |
|---|---|---|---|
| Wi-Fi 4 | n | 802.11n (2009) | MIMO / channel bonding (40 MHz) |
| Wi-Fi 5 | ac | 802.11ac (2014) | 5 GHz only / 80・160 MHz / MU-MIMO (downlink) |
| Wi-Fi 6 | ax | 802.11ax (2019) | OFDMA / 1024-QAM / TWT (power saving) / uplink MU-MIMO |
| Wi-Fi 6E | ax + 6 GHz | 802.11ax extension (2020) | 6 GHz band opened (1200 MHz of new spectrum) |
| Wi-Fi 7 | be | 802.11be (2024) | 320 MHz channels / 4096-QAM / MLO (Multi-Link Operation) / 16 streams |
The substantive shift in Wi-Fi 6 is OFDMA. "From the Wi-Fi 5 model where one client monopolizes the whole channel, to multiplexing many clients along the frequency axis" — in high-density homes/offices with smart appliances and IoT, real-world throughput visibly improves.
Wi-Fi 7's MLO is "stay connected to 2.4 + 5 + 6 GHz simultaneously and dynamically split or duplicate frames across them". When one band gets congested, traffic shifts to the others, so jitter drops — effective for latency-sensitive use cases like XR, cloud gaming, and live video.
If your AP is still Wi-Fi 5 (ac), moving to Wi-Fi 6 is a clear win (homes / small offices with many devices). For Wi-Fi 6E / 7, the gating question is whether you own 6 GHz-capable devices — iPhone 15 Pro and later, Pixel 8 and later, and recent PCs support 6E; older devices stick to 5 GHz and gain little.
The L2 attack surface — anyone can sniff radio #
Because of the wireless nature, "you can't reach this without physically being inside the building" no longer holds. Attacks succeed from the parking lot, the neighboring office, a drone.
| Attack | Mechanism | Defense |
|---|---|---|
| Deauth Flood | Forge Deauth frames to disconnect any client. aireplay-ng -0 is the classic |
Require PMF (802.11w) — management frames become signed and unforgeable |
| Evil Twin / KARMA | Stand up a same-name SSID AP with stronger signal so the device connects unintentionally | WPA3-Enterprise + EAP-TLS + designs that don't trust OS auto-join |
| PMKID attack | Pull the PMKID from a WPA2 AP's Beacon/Association and run offline dictionary attack on the PMK. hcxdumptool + hashcat -m 22000 |
Strong PSK (15+ chars, no dictionary words) or migrate to WPA3-SAE |
| WPS PIN brute force | Exploits the independent halves of the 8-digit PIN to crack it in only ~11,000 tries (Reaver) | Fully disable WPS (off by default on modern APs) |
| Captive Portal MitM | Impersonate a café's "Wi-Fi terms" page and harvest cookies / credentials | Bring up VPN immediately after Wi-Fi connect + HSTS + HTTPS-only |
| KRACK family | Replay 4-way M3 to force nonce reuse; CCMP encrypts with the same key twice → plaintext recovery | OS / AP patches (post-2017) — handled in current OSes |
Hidden SSID leaks the SSID name through Probe Requests from already-connected clients. MAC filtering is bypassed by ip link set address. The classic "felt-secure-but-not-actually-secure" — leave them out of the design.
$ sudo airodump-ng wlan0mon # APs, BSSID, ch, encryption, station count
$ sudo airodump-ng -c 6 --bssid AA:BB:CC:DD:EE:FF -w cap wlan0mon
# Capture a 4-way Handshake (prep for PSK cracking)
$ sudo aireplay-ng -0 1 -a AA:BB:CC:DD:EE:FF -c 11:22:33:44:55:66 wlan0mon
# Get the PMKID alone (PSK crack without WPS or waiting for the handshake)
$ sudo hcxdumptool -i wlan0mon -o capture.pcapng --enable_status=1These techniques can only be performed on networks you administer or with explicit authorization. Running them on someone else's network without permission can violate unauthorized computer-access laws, radio laws, and computer-crime laws in your jurisdiction.
MAC randomization and modern privacy #
Around 2014, iOS / Android / Windows / macOS introduced MAC address randomization, with a different MAC per SSID. The point is to prevent ad tech from tracking a user across locations via the real MAC in Probe Requests (= Wi-Fi tracking ads).
Specifically:
- During Probe Requests, a random MAC is used each time (preventing user identification by nearby APs)
- When connected, a "random MAC fixed per SSID" is used (same MAC across reconnects) — iOS's "Private Wi-Fi Address"
Side effects:
- MAC filtering becomes completely useless (it never was a defense, but now it's also operationally unusable)
- Captive portals see "the prior auth's MAC is a different user" and re-prompt every time
- Enterprise Wi-Fi environments that depend on MAC-auth / DHCP reservations / RADIUS Accounting need to ask users to switch to a fixed MAC per SSID
Don't trust the MAC as an identifier; authenticate with EAP-TLS certificates or SAE client credentials — that's the correct layering. Reserve MAC-based designs for limited use cases like IoT-only SSIDs.
Summary #
- Wi-Fi's complexity grows from two facts: "anyone can sniff the radio" and "the radio has no delivery guarantee"
- The practical order is: (1) connection lifecycle / (2) WPA3 + PMF + EAP-TLS is the modern floor / (3) 2.4/5/6 GHz separation / (4) Hidden SSID and MAC filtering are not defenses
- Add the three of deauth / evil twin / PMKID to that, and "what can I trust the hotel/café Wi-Fi for, and what should I cover with VPN/HTTPS" becomes a question you can answer on your own
