WPA2 vs WPA3, PMF, SAE, 802.1X EAP types, RSN IE analysis, and the attack signatures every Wi-Fi engineer should be able to read in a PCAP.
— Shankar K., Wi-Fi engineer, Irving TX · 15 years 802.11 protocol analysis
RSN Information Element - Reading Security in a PCAP
The RSN IE (id=48) in a Beacon or AssocReq tells you everything about what security the AP is offering and what the client actually negotiated. It is the single most important IE for security diagnosis. Every mismatch between the Beacon RSN IE and the AssocReq RSN IE is a potential authentication failure.
RSN IE structure
Field
What it contains
PCAP filter
What to look for
Group Cipher Suite
Broadcast/multicast encryption. Usually CCMP (AES) or TKIP.
Open networks with encryption (Wi-Fi Enhanced Open). Works on 6 GHz.
24
802.11-2020
SAE-EXT-KEY (GCMP-256)
WPA3-Personal required by newer Wi-Fi 7 certification profiles.
00:40:96 (OUI)
Cisco proprietary
CCKM
Legacy Cisco CCX fast roam
Field note: The most common RSN mismatch I find is a client sending an AssocReq with AKM type 2 (PSK) when the Beacon advertises AKM types 2 and 4 (PSK + FT-PSK). The client chose PSK and bypassed FT entirely. This is usually a driver issue - the client supports FT but the driver picks the first AKM it recognises. Filter: compare wlan_mgt.rsn.akms.type in the Beacon vs the AssocReq for the same client.
WPA2 - RSN with CCMP/AES
WPA2 = 802.11i (RSN) with CCMP/AES as the mandatory cipher. The 4-way handshake derives the PTK (Pairwise Transient Key) from the PMK and two random nonces. CCMP uses AES in counter mode with CBC-MAC for both encryption and integrity. The handshake is visible in every WPA2 connection - capture it, count the frames, read the timing.
4-Way handshake - what each message carries
M1
AP → Client: ANonce
AP sends its random nonce (ANonce). No encryption. Client uses ANonce + its own SNonce + PMK to derive PTK. If you see M1 repeated - the AP is retransmitting because M2 didn't arrive. Replay counter must increment with each M1.
Client sends its SNonce and a MIC (Message Integrity Code) computed using the derived PTK. AP verifies MIC - if it matches, AP knows the client has the correct PMK. Missing M2 = PMKID mismatch or client dropped the frame.
eapol
M3
AP → Client: GTK + Install PTK
AP sends the Group Temporal Key (GTK) encrypted with the PTK, and instructs the client to install the PTK. M3 retransmit more than once = KRACK vulnerability surface. CVE-2017-13077.
eapol
M4
Client → AP: ACK
Client acknowledges GTK installation. Handshake complete - client and AP now share PTK and GTK. Data traffic begins immediately after M4. If you see M4 but no data traffic - IP layer issue (DHCP, DNS), not Wi-Fi security.
eapol
Quick PCAP checks
What you see
Diagnosis
M1 → M2 → M3 → M4 in sequence, <500ms total
Healthy handshake. ✓
M1 repeated 3+ times, no M2
Client not responding - wrong PSK, driver issue, or client dropped M1.
WPA3 has two variants that are often conflated. WPA3-Personal replaces PSK with SAE for home / SMB networks. WPA3-Enterprise replaces WPA2-Enterprise's SHA-1 AKM with SHA-256 (AKM 5) for 802.1X networks. Both mandate PMF. Both are required on 6 GHz. SAE and 802.1X-SHA256 are not interchangeable - they solve different problems.
WPA3-Personal (SAE) - key differences from WPA2-PSK
Property
WPA2-PSK
WPA3-SAE
AKM type in RSN IE
2 (PSK)
8 (SAE)
Offline dictionary attack
Possible - capture handshake, brute-force offline
Not possible - forward secrecy per session
PMF requirement
Optional (MFPC=1 optional)
Mandatory (MFPR=1 required)
Handshake visibility
4-way EAPOL M1-M4 in PCAP
SAE Commit + Confirm frames before EAPOL
Transition mode
N/A
WPA3 Transition Mode: SAE + PSK on same SSID
SAE handshake - what to look for in PCAP
1
SAE Commit (bidirectional)
Both client and AP send a Commit frame - Authentication frame with Auth Algorithm=3 (SAE), Sequence=1. Contains an elliptic curve scalar and element derived from the password. Immune to offline attack - each session uses a fresh random value.
Both sides send a Confirm frame (Auth Algorithm=3, Sequence=2) with a verifier derived from the shared secret. If Confirm fails - wrong password or Dragonblood attack in progress.
After SAE, standard AssocReq/Resp and 4-way EAPOL M1-M4 follow - but now the PMK came from SAE, not a static PSK. The EAPOL exchange looks identical to WPA2 in the frames. PMF is mandatory - management frames are encrypted.
eapol
WPA3-Enterprise - AKM 5 (802.1X-SHA256)
WPA3-Enterprise is 802.1X with SHA-256-based key derivation, not SAE. Client still authenticates via EAP (EAP-TLS, PEAP, TTLS) to a RADIUS server exactly like WPA2-Enterprise. The difference is the AKM suite (5 instead of 1), the PMF requirement (mandatory), and the cipher suite options (CCMP-128 standard, GCMP-256 for the 192-bit "Suite-B" mode used in government / defence).
Property
WPA2-Enterprise
WPA3-Enterprise
WPA3-Enterprise 192-bit
AKM type in RSN IE
1 (802.1X SHA-1)
5 (802.1X SHA-256)
12 (802.1X SHA-384)
PMF requirement
Optional
Mandatory
Mandatory
Cipher suite
CCMP-128
CCMP-128 (GCMP-256 in newer profiles)
GCMP-256 required
EAP method
EAP-TLS, PEAP, TTLS, FAST
Same
EAP-TLS only (with TLS 1.3 cipher restriction)
6 GHz permitted
No
Yes
Yes
Typical use
Enterprise on 2.4/5 GHz
Enterprise on 6 GHz; upgrading from WPA2-Ent
Government, defence, CNSA-compliant networks
Field note: The "WPA3-Enterprise" path on 6 GHz most people deploy is AKM 5 (SHA-256) with CCMP-128, not the 192-bit Suite-B variant. Many client devices don't yet support GCMP-256 so CCMP-128 is still the practical default. Filter wlan_mgt.rsn.akms.type == 5 in a 6 GHz PCAP to confirm.
WPA3 Transition Mode - what it looks like
Transition Mode allows WPA2 (PSK) and WPA3 (SAE) clients on the same SSID during migration. The Beacon RSN IE advertises both AKM type 2 (PSK) and type 8 (SAE). WPA3 clients use SAE - WPA2 clients fall back to PSK. In PCAP: check the AssocReq AKM per client - a WPA3-capable client should use type 8. If it uses type 2, it fell back to WPA2 despite the AP advertising SAE. Transition mode is not permitted on 6 GHz - the AP must advertise AKM 8 (SAE) or AKM 5 (802.1X-SHA256) only.
Vendor PSK-per-user (DPSK / PPSK / iPSK)
Vendor-proprietary schemes assign a unique PSK per user or device while presenting a single SSID. RUCKUS DPSK, Aruba iPSK, Cisco Meraki iPSK, and generic PPSK all fit this pattern. Originally built on WPA2-PSK. For 6 GHz the vendor has to extend the scheme to WPA3-SAE - RUCKUS ships this as DPSK3, which maps per-user keys onto SAE so 6 GHz is usable. Most other vendors have not shipped the SAE variant yet. The trade-off for DPSK3 is onboarding: clients have to bind the passphrase on 2.4 or 5 GHz first before the 6 GHz radio accepts them. Plain DPSK (WPA2) and generic PPSK are not permitted on 6 GHz because the RSN IE cannot advertise a 6-GHz-valid AKM.
Field note: The most common WPA3 deployment failure is mixed-vendor APs where some advertise MFPR=1 (PMF required) and others advertise MFPC=1 (PMF capable but not required). A WPA3 client associating to the MFPC=1 AP may succeed, but a client that moves to the MFPR=1 AP without PMF support will fail. Always verify MFPR consistency across all APs in the ESS - filter wlan_mgt.rsn.capabilities.mfpr in beacons from each BSSID.
PMF - Protected Management Frames (802.11w)
Without PMF, deauthentication and disassociation frames are sent in the clear and can be forged by anyone. An attacker can send a spoofed deauth to any client and disconnect them instantly - no encryption key needed. PMF encrypts these management frames so forged deauths are rejected. Required for WPA3, optional for WPA2.
MFPC vs MFPR - what each bit means
Bit
Name
Meaning
PCAP filter
MFPC=0, MFPR=0
PMF not supported
All management frames in the clear. Deauth forgery trivially possible.
wlan_mgt.rsn.capabilities.mfpc == 0
MFPC=1, MFPR=0
PMF capable
PMF supported but not required. Clients that support PMF use it. Others proceed without.
wlan_mgt.rsn.capabilities.mfpc == 1
MFPC=1, MFPR=1
PMF required
PMF mandatory. Clients without PMF support cannot associate. Required for WPA3.
wlan_mgt.rsn.capabilities.mfpr == 1
How to verify PMF is working in a PCAP
Check
Filter
What healthy looks like
Beacon advertises PMF
wlan_mgt.rsn.capabilities.mfpc == 1
MFPC=1 in every beacon from each BSSID
Client AssocReq confirms PMF
wlan_mgt.rsn.capabilities.mfpc == 1
Client copies MFPC=1 into its AssocReq RSN caps
Deauth frames are protected
wlan.fc.type_subtype == 0x0c
Deauth frames have Protected bit set - payload is encrypted. Forged deauths fail MIC check and are dropped.
SA Query after suspicious deauth
wlan_mgt.fixed.action_code == 8
AP sends SA Query to verify client is still present. PMF mechanism for detecting forged deauths.
Field note: A deauth flood attack with PMF disabled looks like this in a PCAP: dozens of deauth frames per second from a spoofed BSSID, reason code 7 (Class 3 frame from nonassociated station), all clients disconnect simultaneously. With PMF enabled: the deauth frames arrive but carry no valid MIC - clients drop them silently. The attack is visible in the PCAP but has zero effect. Filter wlan.fc.type_subtype == 0x0c and count rate per minute - more than 10/min from a non-AP source = active deauth attack.
Security on 6 GHz - The Wi-Fi Alliance mandate
The 6 GHz band is governed by a clean-slate security policy. No legacy protocols. No WPA2. No transition modes. The Wi-Fi Alliance mandates that APs operating in 6 GHz advertise only WPA3 (Personal or Enterprise) or OWE, with PMF mandatory on all of them. This applies to Wi-Fi 6E and Wi-Fi 7 devices. Non-compliant security modes are not certified and the AP is required to disable the 6 GHz radio or refuse associations on that band.
What's permitted on 6 GHz
Security mode
AKM
Cipher
PMF
Use case
WPA3-Personal (SAE)
8
CCMP-128 (GCMP-256 in newer profiles)
Required
Home, SMB, BYOD
WPA3-Personal with FT
9
CCMP-128 / GCMP-256
Required
WPA3 Personal with 802.11r fast roaming
WPA3-Enterprise (802.1X-SHA256)
5
CCMP-128 (GCMP-256 in newer profiles)
Required
Standard enterprise on 6 GHz
WPA3-Enterprise 192-bit
12
GCMP-256
Required
Government, defence, CNSA-compliant
OWE (Enhanced Open)
18
CCMP-128 (GCMP-256 in newer profiles)
Required
Guest / open networks with encryption
What's prohibited on 6 GHz
Security mode
Why it fails
Where it still works
WPA2-Personal (PSK)
AKM 2 not permitted on 6 GHz. PSK without SAE is vulnerable to offline attack.
2.4 / 5 GHz only
WPA2-Enterprise (802.1X-SHA1)
AKM 1 not permitted on 6 GHz. SHA-1 deprecated.
2.4 / 5 GHz only
WEP, TKIP, open unencrypted
All explicitly banned on 6 GHz.
Nowhere - retire these everywhere
WPA3-Personal Transition Mode
Transition mode advertises both AKM 2 (PSK) and AKM 8 (SAE) - the AKM 2 advertisement disqualifies the RSN IE on 6 GHz.
2.4 / 5 GHz only - the AP must disable transition on 6 GHz automatically
OWE Transition Mode
OWE Transition exposes the legacy open SSID, which is prohibited on 6 GHz.
2.4 / 5 GHz only
WPA2-based DPSK / PPSK / iPSK
Vendor PSK-per-user schemes built on WPA2-Personal cannot advertise a 6-GHz-valid AKM. RUCKUS DPSK3 over SAE is the exception.
2.4 / 5 GHz unless the vendor ships the WPA3-SAE variant
Wi-Fi 7 additional mandates (802.11be)
Wi-Fi 7 certification added Beacon Protection on top of PMF - a Management MIC Information Element in the beacon itself, so associated clients can verify the beacon wasn't tampered with. Wi-Fi 7 also tightened the cipher story: newer profiles require GCMP-256 (AKMs 24/25 for SAE-EXT-KEY and its FT variant), though CCMP-128 is still widely deployed for client compatibility. Hash-to-Element (H2E) is mandatory for SAE on Wi-Fi 6E / Wi-Fi 7 - the older Hunting-and-Pecking SAE variant is not certified for 6 GHz.
Verifying 6 GHz security compliance in a PCAP
Check 1
AKMs advertised in the 6 GHz beacon
Filter the beacon from a 6 GHz BSSID. The RSN IE AKM suite list should contain only AKM 5, 8, 9, 12, 18, 24, or 25. Any presence of AKM 1 or 2 means the AP is non-compliant or transition mode is incorrectly enabled on 6 GHz.
In the same beacon, verify the RSN Capabilities field shows MFPR=1 (mandatory) not just MFPC=1 (capable). Optional PMF is not 6-GHz-compliant.
wlan_mgt.rsn.capabilities.mfpr == 1
Check 3
H2E for SAE (if AKM 8 or 9)
If AKM 8 or 9 is present, check the SAE Commit frame for the Hash-to-Element indicator in the Status Code field. Auth Algorithm=3 Sequence=1 with status code 126 (SAE_HASH_TO_ELEMENT) confirms H2E. Status code 0 alone means legacy HnP, which is non-compliant on 6 GHz.
For certified Wi-Fi 7 APs, beacons should carry the Management MIC IE. Its presence proves the AP is signing its beacons - a mandatory feature for full Wi-Fi 7 certification as of 2025 controller releases.
wlan_mgt.tag.number == 140
Field note: The most common 6 GHz security misconfiguration in enterprise deployments is transition mode enabled on a controller-wide basis and not automatically disabled on 6 GHz radios. The AP ends up advertising a 6-GHz-invalid RSN IE, and Wi-Fi 7 clients refuse the association silently (no deauth frame, just no response). The PCAP signature: AssocReq on 6 GHz → no AssocResp → client retries on 5 GHz. Verify by checking if AKM 2 or 1 appears in the 6 GHz beacon; if so, the AP firmware isn't correctly enforcing the 6 GHz transition disable rule.
802.1X and EAP - Enterprise Authentication
Enterprise Wi-Fi uses 802.1X for authentication - the AP acts as an authenticator, the client is the supplicant, and a RADIUS server is the authentication server. EAP (Extensible Authentication Protocol) runs inside 802.1X. The specific EAP method determines how credentials are verified and what a failure looks like in a PCAP.
EAP methods - comparison
Method
Credential type
PCAP frames
Common failure
EAP-TLS
Client certificate + CA
TLS handshake inside EAPOL. Many frames (10-20). Certificate exchange visible.
Cert expiry. CA mismatch. CRL unreachable. Silent EAP-Failure.
PEAP
Username + password (inside TLS tunnel)
TLS handshake (shorter than EAP-TLS). MSCHAPv2 inside tunnel.
Server cert not trusted by client. Wrong domain suffix. RADIUS timeout.
EAP-TTLS
Various inner methods
Similar to PEAP but supports more inner protocols (PAP, CHAP, MSCHAPv2).
Inner method mismatch. Server cert issues.
EAP-FAST
PAC (Protected Access Credential)
PAC provisioning visible in first connection. Subsequent connections shorter.
PAC expired. PAC not provisioned.
EAP-TLS failure patterns in PCAP
Pattern 1
Cert expiry - silent abort
TLS handshake proceeds normally through Certificate exchange. RADIUS server checks NotAfter field. Sends EAP-Failure without explanation. Client sees deauth. Classic Monday morning outage when cert expired over the weekend.
eap && eap.code == 4 (EAP-Failure) - watch for it immediately after Certificate frame
Pattern 2
CA mismatch - client aborts TLS
RADIUS server sends its certificate. Client checks issuing CA. If CA is not in the client's trusted store - or if the supplicant is configured to prompt the user - the TLS handshake aborts at the Certificate Verify stage. Client sends TLS Alert.
eap - look for TLS Alert (21) record type after Certificate frame
Pattern 3
RADIUS timeout - EAPOL silence
Client sends EAPOL-Start or Identity Response. AP receives it and forwards to RADIUS. RADIUS is unreachable or overloaded. No EAP response arrives. AP retransmits Identity Request 3 times then disassociates client. PCAP shows Identity Request retransmits with no response from RADIUS direction.
Field note: EAP-TLS cert expiry is the #1 cause of enterprise Wi-Fi outages and the hardest to diagnose without a PCAP. The controller logs show "authentication failed" with no cert detail. The PCAP shows: EAP-Request Identity → EAP-Response Identity → TLS exchange begins → Certificate frame → immediate EAP-Failure. The gap between Certificate and EAP-Failure is milliseconds - the RADIUS server rejected the cert before completing the handshake. Check X.509 NotAfter in the Certificate frame content in Wireshark.
Attack Signatures - What to Look for in a PCAP
Every Wi-Fi attack leaves a protocol signature. These are the patterns I look for when diagnosing a suspected attack - each with the exact Wireshark filter to find it.
Attack
CVE
PCAP signature
Filter
Defense
Deauth flood
CVE-2019-15126
10+ deauth frames/minute from a BSSID that is not the real AP. Reason code 7 most common. All clients disconnect simultaneously.
wlan.fc.type_subtype == 0x0c
Enable PMF (802.11w). MFPR=1 makes deauth forgery ineffective.
Evil Twin / Rogue AP
CVE-2023-52424
Same SSID, different BSSID/OUI. Often weaker RSN IE (TKIP vs CCMP) or missing PMF. RSSI unusually strong in an unexpected location. Beacon interval slightly different.
wlan_mgt.ssid == "YourSSID"
Enable 802.11w PMF. Use certificate-based authentication (802.1X). Monitor OUI of APs advertising your SSID.
KRACK
CVE-2017-13077
EAPOL M3 retransmitted more than once to same client. Attacker replaying M3 to force nonce reuse. Replay counter in M3 does not increment.
eapol
Enable PMF. Patch all clients. 802.11w-protected M3 cannot be replayed by third party.
PMKID attack
—
Attacker captures a single AssocReq containing the PMKID and runs offline dictionary attack against it. No full 4-way handshake needed.
wlan_mgt.rsn.pmkid
Use WPA3-SAE - no PMKID exposed. Or use long random PSK (20+ chars) that resists dictionary attack.
Dragonblood
CVE-2019-9496
Repeated SAE Commit frames with different anti-clogging tokens. Attacker attempts timing side-channel on SAE. SAE Commit without corresponding Confirm.
wlan_mgt.fixed.auth_alg == 3
Patch AP firmware. Enable anti-clogging token. Rate-limit SAE Commit frames.
SSID Confusion
CVE-2023-52424
Client connects to wrong network when Beacon IE manipulation causes SSID mismatch. Client sees correct SSID in scan but connects to attacker's AP. Visible as BSSID/SSID mismatch in consecutive probe/assoc frames.
wlan_mgt.ssid
Enable 802.11w. Use unique SSID per network. Avoid reusing SSIDs across trusted/untrusted networks.
Field note: The evil twin is the most common attack I see reported in enterprise environments - and the most frequently misidentified. A misconfigured rogue AP from a neighbouring office running the same SSID is not an attack, but it looks identical in a quick scan. In a PCAP, compare the RSN IE of the suspected rogue against the legitimate APs: cipher suite differences, missing PMF, different beacon interval, and OUI mismatch are the four tells. WiFi Analyser's Rogue AP detector checks all four automatically.
Audit Wi-Fi security from a PCAP
WiFi Analyser checks RSN IE mismatches, PMF status, EAPOL completeness, rogue AP signatures, and deauth flood patterns - automatically from your PCAP upload.