Wi-Fi (IEEE 802.11) #

Wi-Fi (IEEE 802.11) is the wireless LAN protocol that, by overwhelming margin, is how devices reach the Internet — at home, in cafés, at work, at airports. It shares Ethernet's MAC + EtherType + Payload frame format, but the wireless side runs on fundamentally different physics, so it has to carry layers a wired LAN never needed to think about — the connection process / encryption / collision avoidance / speed and channel selection.

Behind "enter the SSID and password and you're online" is actually a 6-to-10-step negotiation: listen for Beacons → actively probe → Open System auth → association → 4-way Handshake to derive crypto keys → DHCP → data. This article opens by expanding that hidden sequence into one diagram, then walks the WPA generations and crypto / physical layer (frequencies and channels) / what changed in Wi-Fi 6 / 6E / 7 / L2 attack surface / the post-MAC-randomization privacy era. Comparison with Ethernet lives in the Ethernet article; this one stays focused on what's different because it's wireless.

1. Why wireless is fundamentally unlike wired #

Wi-Fi is L2 just like Ethernet, but its specification is much heavier because it rides a shared medium — radio.

The design philosophy of "collisions can't be detected, so we avoid them" (CSMA/CA, Carrier Sense Multiple Access with Collision Avoidance) is the root divergence from Ethernet's CSMA/CD. Before transmitting, a station inserts a DIFS (DCF Inter-Frame Space) plus a random backoff drawn from the contention window; if the channel stays quiet during that, it sends, otherwise the counter resumes. Every frame demands an ACK, and missing it triggers binary exponential backoff retransmission.

The "hidden node problem" — A and C both reach the AP but can't sense each other, so CSMA/CA misses their collisions — has an optional RTS/CTS (Request To Send / Clear To Send) handshake to fix it, but it's expensive enough that high-density modern APs usually don't enable it.

This whole story underlies the everyday user observations: "Wi-Fi only delivers half to two-thirds of the rated speed," "adding people slows it linearly," "5 GHz is fast but doesn't reach the back room."

2. The connection lifecycle — from tapping the SSID to getting an IP #

Six stages of negotiation actually run before "you're connected to Wi-Fi." In monitor-mode Wireshark capture, you can see all of them in well under a second.

The takeaways:

• Beacons are sent by the AP every ~100 ms continuously. The Wi-Fi list on your phone is just listening to those broadcasts — "seeing the SSID list ≠ trying to connect." "Hidden SSID doesn't put the SSID name in the Beacon," but the SSID rides in the Probe Request, so it leaks anyway and doesn't constitute meaningful security.
• Open System Authentication is a WEP-era artifact; today it's effectively just "hello." Real authentication is the 4-way Handshake that follows.
• The 4-way Handshake (EAPOL) is the heart of WPA2/WPA3. It derives a PTK (per-session key) from the PMK (pre-shared key) and uses MIC verification to prove that both sides hold the same PMK. All four frames are EAPOL (EAP over LAN, EtherType=0x888E).
• PTK formula: PTK = PRF(PMK, ANonce, SNonce, AP MAC, STA MAC) — mixing both sides' nonces gives a different key per session (close to PFS). Even if PMK is reused, session keys are not.

Under WPA2-Enterprise (802.1X), EAP runs in place of Open System (EAP-TLS / PEAP / EAP-TTLS). A RADIUS server is the auth backend, and identification is certificate-based (EAP-TLS) or AD-password-based (PEAP-MSCHAPv2). The 4-way Handshake still runs after EAP completes — that part is the same.

# Scan APs on Linux (root + NetworkManager family)
nmcli device wifi list                # Channel / signal / security
sudo iw dev wlan0 scan | grep -E "SSID|signal|Authentication suites"

# Details on the connected AP (channel width / MCS / RSSI)
iw dev wlan0 link
iw dev wlan0 station dump

# Monitor mode (for packet analysis) — not needed for everyday use
sudo iw dev wlan0 set monitor control

3. The WPA generations — WEP / WPA / WPA2 / WPA3 #

Because anyone can intercept the radio, encryption was mandatory from day one. But the story has been "the first scheme broke, the next broke, the next broke…" for a quarter century.

The decisive difference of WPA3's SAE vs WPA2-PSK: in WPA2-PSK, PMKID = HMAC(PMK, …) rides in the AP's Beacon/Association exchanges, so a single captured frame is enough to start an offline dictionary attack on the PSK (hashcat -m 22000). SAE's math (Dragonfly key exchange over a finite field) means the cleartext exchanges don't reveal anything from which PMK can be derived — so even a weak PSK survives dictionary attacks.

PMF (Protected Management Frames, 802.11w) encrypts management frames such as Auth / Deauth / Disassoc. Without it, an attacker can forge Deauth frames to disconnect any client at will (= the Wi-Fi DoS / evil-twin lever). WPA3 mandates PMF; WPA2 supports it as an option.

# Check the encryption you're connected with
nmcli connection show <CONN-NAME> | grep -i security
iw dev wlan0 link                     # appears as "RSSI: ... CCMP/GCMP"

The 2026 selection: new builds — WPA3-Personal (SAE) + PMF mandatory. For backward compatibility, WPA3/WPA2 transition mode is acceptable, but flip to WPA3-only once WPA2-only devices are gone. For enterprise, WPA3-Enterprise + EAP-TLS (certificates) is the right answer. Don't hide the SSID (pointless, as above), and don't rely on MAC filtering (trivially spoofable) — both are textbook examples of "makes you feel safe, doesn't actually protect."

4. The physical layer — frequency bands and channel widths #

Most "Wi-Fi is slow / Wi-Fi keeps dropping" complaints stem from physical-layer congestion, so the basics of frequency bands and channels are very much worth knowing.

The takeaways:

• 2.4 GHz is congested — narrow band, only ch 1, 6, 11 non-overlap. Neighbors' APs, Bluetooth, microwaves, wireless mice all crowd here. Slow, but penetrates walls. IoT devices (smart locks, smart bulbs) still default to it.
• 5 GHz is fast and uncongested — wider widths (80/160 MHz) per channel. Lower wall penetration, shorter range. DFS (Dynamic Frequency Selection) regions (5.25–5.72 GHz, parts of Japan's W53/W56) are legally required to yield to weather/maritime radar, leading to AP outages of seconds to minutes during evacuation — a frequent cause of "it sometimes drops."
• 6 GHz is the new band (2020–) — exclusive to Wi-Fi 6E / Wi-Fi 7. No legacy = no congestion, 320 MHz width (Wi-Fi 7) for theoretical 5+ Gbps. WPA3 mandatory, range shorter than 5 GHz.

MCS (Modulation and Coding Scheme) is the "speed step" picked by the current SNR. Close to the AP, MCS climbs to 4096-QAM (Wi-Fi 7); farther out, it falls 256-QAM → 64-QAM → BPSK → no link. "It gets slower as I walk away" is exactly this.

MIMO / MU-MIMO / OFDMA:

• MIMO (Multiple Input Multiple Output) — multiple antennas → spatial multiplexing. 2 streams to one client → 2× speed (standardized in Wi-Fi 5)
• MU-MIMO (Multi-User MIMO, Wi-Fi 5/6) — simultaneous distinct streams to multiple clients
• OFDMA (Orthogonal Frequency Division Multiple Access, Wi-Fi 6) — slice the channel along the frequency axis (RUs = Resource Units), packing many small clients in parallel. Pays off in dense IoT environments.

5. Wi-Fi 6 / 6E / 7 — what changed #

The substantive change in Wi-Fi 6 is OFDMA, taking us from "one client owns the whole channel" (everything through Wi-Fi 5) to "slice the channel by frequency to serve many clients in parallel." In dense smart-home / IoT environments, the effective throughput improvement is visible.

Wi-Fi 7's MLO is "stay attached to multiple bands simultaneously (2.4 + 5 + 6 GHz) and dynamically distribute and replicate frames across them." If one band gets congested, you reroute to another — jitter drops, which matters for XR, cloud gaming, and video streaming.

When to upgrade: if your AP is Wi-Fi 5 (ac), moving to Wi-Fi 6 is a clear win (especially as device counts grow at home or in small offices). Wi-Fi 6E / 7 hinges on whether you have 6 GHz client devices — iPhone 15 Pro+, Pixel 8+, recent PCs are 6E; older devices stay on 5 GHz, so the benefit is bounded.

6. The L2 attack surface — anyone can intercept the radio #

Because of the wireless physics, "the attacker has to physically enter the building" doesn't apply. Attacks succeed from the parking lot, the next office, or a drone overhead. The Wi-Fi-specific attacks worth knowing:

"Hidden SSID" and "MAC address filtering" are worthless as defenses. Hidden SSID still rides in Probe Requests — it leaks from connecting clients; MAC filtering is trivially defeated by ip link set address spoofing. Classic "makes you feel secure but doesn't secure" — drop them at design time.

# Observe nearby APs / clients (NIC must support monitor mode)
sudo airodump-ng wlan0mon              # AP, BSSID, ch, encryption, station counts
sudo airodump-ng -c 6 --bssid AA:BB:CC:DD:EE:FF -w cap wlan0mon  # focus one AP

# Capture a 4-way Handshake (preparation for PSK cracking)
sudo aireplay-ng -0 1 -a AA:BB:CC:DD:EE:FF -c 11:22:33:44:55:66 wlan0mon  # one deauth → forces a reconnect

# Lift the PMKID alone (no waiting for WPS or 4-way)
sudo hcxdumptool -i wlan0mon -o capture.pcapng --enable_status=1

Run these only on networks you administer or have explicit authorization for. Doing this on someone else's network is unauthorized access and falls under unauthorized-access / computer-crime / radio law in essentially every jurisdiction.

7. MAC randomization and modern privacy #

Around 2014, iOS / Android / Windows / macOS introduced per-SSID MAC address randomization. The trigger: with the real MAC riding in Probe Requests, ad networks could track a user across locations by MAC (= Wi-Fi tracking advertising) — randomization defeats this.

In practice:

• During Probe Requests, a fresh random MAC is used (no stable identifier to nearby APs)
• During connection, a "random MAC fixed per SSID" is used (so reconnects keep the same MAC) — iOS calls this "Private Wi-Fi Address"

Side effects:

• MAC address filtering is fully neutered (it was never useful, but it's now unusable operationally)
• Captive portals treat "the previously authenticated MAC" as a different person every time, demanding re-authentication
• Enterprise Wi-Fi using MAC auth / DHCP reservations / RADIUS Accounting must ask users to set "fixed MAC for this SSID"

In a modern secure Wi-Fi design, you don't trust the MAC as an identifier, and identification belongs to the EAP-TLS certificate / SAE client credential layer.

Wi-Fi is "the same L2 frame format as Ethernet, on radio," but the shared-medium nature of radio introduces every layer the wired world didn't need — CSMA/CA / half-duplex / L2 retransmission / 4-way Handshake / WPA generations / DFS / MAC randomization. None of these are independent inventions; they all derive from the two basic facts that anyone can intercept the radio and the radio doesn't guarantee delivery.

Practical reading order: "hold the connection lifecycle in your head" → "know that WPA3 + PMF + EAP-TLS is the modern floor" → "pick the right band among 2.4/5/6 GHz" → "know that Hidden SSID / MAC filter aren't defenses." Add a working sense of deauth / evil twin / PMKID and you have your own judgment for "what to entrust to the hotel/café Wi-Fi vs. what to wrap in VPN/HTTPS."