EAPOL Packets Explained: What They Are and How They're Structured

EAPOL Packets Explained: What They Are and How They're Structured

When you connect to a WPA2 network, your device and the access point exchange a series of packets that prove both sides know the password without either side ever transmitting it. Those packets are EAPOL frames. If you've ever captured a wireless handshake, every one of those handshake packets is an EAPOL frame.

Understanding EAPOL at the byte level isn't just academic. It tells you exactly what you've captured, why it matters, and what you can and can't do with it. It also explains why passive capture works - you don't need to inject anything to get the data you need for an authorized audit.

What Is EAPOL?

EAP stands for Extensible Authentication Protocol. It's a framework defined in RFC 3748 that describes how authentication information is exchanged - but it says nothing about how that information is transported over a specific link type. EAP is transport-agnostic by design.

EAPOL - EAP over LAN - is the transport mechanism defined in IEEE 802.1X that carries EAP frames over wired and wireless Ethernet links. The "LAN" in the name is historical. In practice, EAPOL is used almost exclusively for WiFi authentication today.

In the context of WPA2 personal (PSK) networks, EAPOL is used for a specific subset of its capability: the EAPOL-Key frame type, which carries the 4-way handshake. On enterprise networks (WPA2-Enterprise), full EAP exchanges also ride over EAPOL.

802.1X authentication: the supplicant (client), authenticator (AP), and auth server exchange EAP messages carried inside EAPOL frames. (Diagram: Wikimedia Commons, CC BY-SA 3.0)

graph LR
    subgraph ETH["Ethernet Frame"]
        DST["Dest MAC
6B"] --> SRC["Src MAC
6B"]
        SRC --> ETYPE["EtherType
0x888E"]
        ETYPE --> EAPOL["EAPOL Payload"]
    end
    subgraph EAPOL_DETAIL["EAPOL Header"]
        VER["Version
1B"] --> TYPE["Packet Type
1B"]
        TYPE --> LEN["Body Length
2B"]
        LEN --> BODY["Packet Body
variable"]
    end
    EAPOL --> EAPOL_DETAIL

EAPOL frame encapsulation - the EAPOL header sits inside a standard Ethernet frame identified by EtherType 0x888E

Where EAPOL Sits in the Stack

EAPOL frames are identified by EtherType 0x888E. This value appears in the Ethernet frame header's EtherType field (bytes 12-13 of a standard Ethernet II frame), placing EAPOL at Layer 2.

The stack looks like this:

[ Ethernet II Header    ]  - DA (6B), SA (6B), EtherType 0x888E (2B)
[ EAPOL Frame           ]  - Version, Type, Length, Body
[ EAP or EAPOL-Key Data ]  - The actual authentication content

In a WiFi capture, the Ethernet header is replaced by the 802.11 frame header, but the EtherType still identifies the payload as EAPOL. When you open a handshake PCAP in Wireshark, the protocol column shows "EAPOL" for all four handshake packets, and the EtherType 0x888E is visible in the 802.11 logical link control (LLC) layer.

EAPOL operates before IP addressing. There are no IP headers in EAPOL frames. The client doesn't have an IP address yet when the handshake runs - EAPOL is part of the link establishment process that precedes DHCP.

Standard 802.11 frame layout. EAPOL data travels inside the frame body of 802.11 data frames. (Diagram: Wikimedia Commons, CC BY-SA 3.0)

EAPOL Frame Structure

Every EAPOL frame starts with a 4-byte header:

Version (1 byte): EAPOL version. 0x01 for 802.1X-2001, 0x02 for 802.1X-2004, 0x03 for 802.1X-2010. WPA2 handshakes typically use version 0x01 or 0x02. Many implementations send 0x01 regardless of actual 802.1X version for compatibility.

Packet Type (1 byte): Identifies the type of EAPOL packet:

• 0x00: EAP-Packet (carries a full EAP frame - used in WPA2-Enterprise)
• 0x01: EAPOL-Start (client signals it wants to authenticate)
• 0x02: EAPOL-Logoff (client signals it's done)
• 0x03: EAPOL-Key (carries key derivation data - this is the WPA2 handshake)
• 0x04: EAPOL-Encapsulated-ASF-Alert (rarely seen)

For WPA2 personal networks, all four handshake packets use Packet Type 0x03 (EAPOL-Key).

Packet Body Length (2 bytes): Length of the EAPOL body in bytes, big-endian. Does not include the 4-byte EAPOL header itself. For WPA2 handshake frames, this is typically 95 bytes (for messages without Key Data) or larger when Key Data is present.

Packet Body (variable): The actual content. For EAPOL-Key frames, this is the EAPOL-Key structure described below. For EAP-Packet frames, this is an EAP header followed by EAP method data.

EAPOL-Key Frame Structure

The EAPOL-Key body is the critical structure for WPA2 handshake analysis. It's 95 bytes minimum, structured as follows:

Key Descriptor Type (1 byte): Identifies the key descriptor format. 0x01 is RC4 (used in WEP/TKIP, legacy). 0x02 is RSN (Robust Security Network) - this is the EAPOL descriptor used in WPA2. When you see 0x02 here, you're looking at a WPA2 handshake frame.

Key Information (2 bytes): A bitfield encoding multiple properties of the key exchange. Critical bits:

• Bits 0-2: Key Descriptor Version (001 for HMAC-MD5/RC4, 010 for HMAC-SHA1-128/AES, 003 for AES-128-CMAC)
• Bit 3: Key Type (1 = Pairwise, 0 = Group)
• Bits 4-5: Key Index (only used for group keys)
• Bit 6: Install flag (1 = install the key after this message)
• Bit 7: Key ACK (1 = receiver should send a response)
• Bit 8: Key MIC (1 = a MIC is present in the MIC field)
• Bit 9: Secure (1 = PTK has been established)
• Bit 10: Error
• Bit 11: Request
• Bit 12: Encrypted Key Data
• Bit 13: SMK Message

The Key Information bitfield is what distinguishes the four handshake messages from each other. You can determine which message you're looking at by examining these bits.

Key Length (2 bytes): Length of the pairwise temporal key in bytes. Typically 16 (128-bit) for CCMP or 32 (256-bit) for GCMP-256.

Key Replay Counter (8 bytes): A monotonically increasing counter used to prevent replay attacks. The AP sets this in message 1 and increments it for each new handshake. The client echoes the counter in its responses. If a response arrives with a lower counter than expected, it's discarded.

Key Nonce (32 bytes): The cryptographic nonce for this side of the exchange. In message 1, this is the ANonce (AP nonce). In message 2, this is the SNonce (client nonce). Messages 3 and 4 also carry the ANonce. These nonces are essential for PTK derivation.

Key IV (16 bytes): Initialization vector. Used with TKIP; all zeros in CCMP/WPA2.

Key RSC (8 bytes): Receive Sequence Counter. Used with group keys (GTK) to prevent replay of previously seen group-addressed frames. Zero in messages 1 and 2.

Reserved (8 bytes): All zeros. Ignored.

Key MIC (16 bytes): Message Integrity Code. A keyed hash over the entire EAPOL-Key frame (with this field zeroed out during calculation). Present in messages 2, 3, and 4. The MIC is computed using KCK (Key Confirmation Key), which is derived from the PTK. This is the field that makes offline cracking possible.

Key Data Length (2 bytes): Length of the Key Data field in bytes. Zero when no Key Data is present.

Key Data (variable): Contains the GTK (Group Temporal Key) in message 3, encrypted with KEK (Key Encryption Key). Also carries RSN information elements (RSNIE) in messages 2 and 3. Empty in messages 1 and 4.

graph TD
    KEY["EAPOL-Key Frame Body"] --> DESC["Key Descriptor Type
1B - RSN or WPA"]
    KEY --> INFO["Key Information
2B - flags and version"]
    KEY --> KLEN["Key Length
2B"]
    KEY --> REPLAY["Replay Counter
8B"]
    KEY --> NONCE["Key Nonce
32B - ANonce or SNonce"]
    KEY --> IV["Key IV
16B"]
    KEY --> RSC["Key RSC
8B"]
    KEY --> MIC["Key MIC
16B - integrity check"]
    KEY --> KDATA["Key Data
variable - GTK, PMKID"]

EAPOL-Key frame body fields - the nonce and MIC fields are critical for the WPA2 4-way handshake and are the primary targets in handshake capture attacks

sequenceDiagram
    participant C as Client
    participant AP as Access Point
    Note over C,AP: Both derive PMK from password + SSID
    AP->>C: EAPOL-Key: ANonce (Message 1)
    Note over C: Derives PTK from PMK + ANonce + SNonce
    C->>AP: EAPOL-Key: SNonce + MIC (Message 2)
    Note over AP: Derives PTK, verifies MIC
    AP->>C: EAPOL-Key: GTK + MIC (Message 3)
    Note over C: Installs PTK and GTK
    C->>AP: EAPOL-Key: ACK + MIC (Message 4)
    Note over C,AP: Encrypted data transfer begins

The four EAPOL-Key messages that comprise the WPA2 handshake - capturing Messages 1 and 2 provides enough data for offline password cracking

The Four WPA2 Handshake Messages

The four EAPOL-Key messages can be distinguished by their Key Information field:

Message 1 (AP to Client):

• Key Type = 1 (Pairwise)
• Key ACK = 1 (client must respond)
• Key MIC = 0 (no MIC yet)
• Install = 0
• Secure = 0

Contains: ANonce in the Key Nonce field. No MIC. Key Data is empty. The client receives this and now has everything it needs (ANonce, its own generated SNonce, the PMK, and both MAC addresses) to derive the PTK.

Message 2 (Client to AP):

• Key Type = 1 (Pairwise)
• Key ACK = 0
• Key MIC = 1 (MIC is present)
• Install = 0
• Secure = 0

Contains: SNonce in the Key Nonce field. MIC calculated with KCK. Key Data contains the client's RSNIE. This is the frame that, combined with message 1, gives a passive observer everything needed to attempt offline cracking: both nonces and the MIC to check against.

Message 3 (AP to Client):

• Key Type = 1 (Pairwise)
• Key ACK = 1
• Key MIC = 1
• Install = 1 (client should install PTK)
• Secure = 1
• Encrypted Key Data = 1

Contains: ANonce again. MIC. Encrypted GTK in Key Data field. The AP has derived the same PTK, verified the MIC from message 2, and is now sending the GTK so the client can receive broadcast/multicast traffic.

Message 4 (Client to AP):

• Key Type = 1 (Pairwise)
• Key ACK = 0
• Key MIC = 1
• Install = 0
• Secure = 1

Contains: MIC. Empty Key Data. This is the ACK - the client confirms it has installed the keys. After this frame, both sides start using the PTK for data frame encryption.

Why EAPOL Matters for Security Research

Handshake capture for password auditing: Messages 1+2 (or messages 2+3, which also contain both nonces) give you everything needed to test a password against a WPA2 network you own or have permission to audit. The captured data is deterministic: given a password candidate, you can derive the PMK, then the PTK, then recalculate the MIC and check whether it matches the one in message 2. Tools like hashcat accept PCAP files and do exactly this at hardware-accelerated speed.

PMKID extraction: Since 2018, there's been a method to perform offline cracking without capturing a full 4-way handshake. The PMKID is a value computed as HMAC-SHA1-128(PMK, "PMK Name" || BSSID || client MAC). It's included in the RSNIE of message 1 (or obtainable by sending an association request). Because the PMKID is derived from the PMK (which is derived from the password), you can test password candidates against the PMKID alone without waiting for a client to connect. This is significant because it allows testing against APs even when no clients are present.

Protocol implementation analysis: EAPOL replay counter handling, nonce reuse, and MIC verification are all areas where implementations have had bugs. Analyzing captured EAPOL exchanges lets you verify that both APs and clients are implementing the protocol correctly.

BLEShark Nano and EAPOL Capture

The BLEShark Nano captures EAPOL frames and saves them as standard PCAP files, compatible with Wireshark, hashcat, and other analysis tools.

In standard mode (for use on networks you own or have written permission to test), BLEShark Nano can trigger client reconnections by sending deauthentication frames, then immediately switch to passive capture to record all four EAPOL-Key messages as they arrive. The resulting PCAP contains the complete handshake, ready for import into your auditing workflow.

In EU passive mode, BLEShark Nano only captures EAPOL frames that occur during natural association events - when clients connect without any induced deauth. This mode is appropriate for monitoring your own network's authentication activity: detecting unauthorized clients attempting to associate, identifying devices with slow or failing handshake completion, or auditing that your AP's EAPOL implementation is sending well-formed frames.

Passive mode PMKID extraction is also supported. Since the PMKID appears in message 1 without any client interaction required, BLEShark Nano can extract PMKIDs from APs in range purely by listening, enabling offline password testing against your own access points without waiting for a client to connect.

All captures are saved as standard PCAP format. No proprietary format, no locked-in toolchain. You take the files and use whatever analysis tools you prefer.

BLEShark Nano is designed for authorized security research and educational use. EAPOL capture and handshake analysis should only be performed on networks you own or have explicit written permission to test.

Get BLEShark Nano - $36.99+