MLO 4-Way Handshake Visualizer

Under Enhanced Multi-Link Multi-Radio operation, the single PTK at MLD level is paired with a SHARED packet-number (PN) space across all simultaneously-active links. If firmware does not synchronize PN updates across the radio chain, replay-counter desync can surface on one link while the others continue normally. Observable in PCAP as PN regression on one link, PN advancing normally on others, both encrypted with the same PTK.

WPA3 with GCMP-256 + SAE-PT + 256-bit AKM uses 512-bit PTK output instead of 384-bit. The extension introduces KCK2 (24 bytes) and KEK2 (32 bytes) for MIC and key-wrap operations on Management Frame Protection. MLO with this cipher suite uses MIC field length 32 bytes (HMAC-SHA-384) instead of 16 bytes (HMAC-SHA-1).

When one link of an MLD fails and recovers, the GTK rotation on that link does NOT trigger a full 4-way handshake. The AP unicasts a Group Key Handshake (M5 / M6, 2-way group handshake) delivering the new GTK via MLO GTK KDE for the recovered link only. PTK is untouched.

The Link ID byte inside MLO GTK / IGTK / BIGTK KDE uses bit positions 4 to 7 (high nibble) for the link ID itself. Bits 0 to 3 are reserved. So a Link ID value of 0x2 renders in Wireshark as bit-field "0010 .... = LinkID: 0x2" -- the 0x0010 prefix is bit-position notation, not an offset.

Even when Beacon Protection and Management Frame Protection are negotiated at the MLD level, the actual IGTK and BIGTK are PER LINK. A management frame received on Link 0 is verified against Link 0’s IGTK regardless of which link the handshake completed on. Implementation bugs that conflate "PMF at MLD" with "IGTK shared across links" produce silent MIC verification failures.

If a client capable of MLO chooses to associate as non-MLO with an MLO-capable AP (driver decision or capability mismatch), the handshake runs in classic mode with only per-link MAC and per-link keys. The AP must NOT include MLO KDEs in M1 or M2 even though it is MLO-capable. PCAP signature: standard 4-way handshake, no MLO Link KDE, no MLO GTK KDE. This is correct behavior, not a downgrade attack.

A Wi-Fi 7 phone associates with an MLO AP successfully. Unicast traffic works fine across all three bands. But the phone never receives mDNS advertisements from the printer on the local subnet. Other devices on the same SSID see the printer fine.

The MLO handshake completed and the phone installed the unified PTK at the MLD level. Unicast frames work. But the AP firmware bug assembled the same Link ID into both 2.4 GHz and 5 GHz MLO GTK KDEs in M3, so the phone installed only one GTK (overwrite) and only decrypts broadcasts on one link. The printer broadcasts mDNS on the link the phone is not listening on. To the user it looks like an mDNS / Bonjour issue.

A packet capture shows the MLO GTK KDEs in M3 with identical Link IDs. The visualizer renders the byte-level KDE so you can spot the duplication immediately. Comparing across vendors, you can see whose firmware assembles MLO GTK KDEs correctly with sequential Link IDs (0, 1, 2) and whose does not.

A Wi-Fi 7 device with Multi-Link Operation can be on 2.4 GHz, 5 GHz, and 6 GHz at the same time with the same AP. They run ONE 4-way handshake to set this up, not three. The pairwise key that protects unicast traffic (the PTK) is the same across all three bands.

But each band gets its own group key for broadcast traffic (the GTK). That is the new part. The AP tells the client "here is GTK for Link 0 (2.4 GHz), here is GTK for Link 1 (5 GHz), here is GTK for Link 2 (6 GHz)" all in Message 3 of the handshake, packaged as separate Key Data Elements.

To prove all of this works, the client's MIC in Message 4 is computed using the new PTK. If the AP can verify that MIC, both sides have proven they derived the same PTK from the same PMK, MLD MAC addresses, and nonces.

The PTK in MLO is computed exactly like classic 4-way: PTK = PRF(PMK, ANonce, SNonce, Min(A,S), Max(A,S)). The difference is A and S. In classic 4-way, A is the AP MAC and S is the client MAC. In MLO, A is the AP MLD MAC and S is the client MLD MAC. The MLD MAC is a virtual MAC that identifies the device as a multi-link entity; each link has its own MAC, but the MLD MAC is what the handshake binds to.

The AP MLD MAC is told to the client in Message 1 via the MAC Address KDE (Key Data Element, OUI 00:0f:ac, type 3). This field does not exist in classic 4-way. The client's MLD MAC is told back in Message 2 via the same KDE type.

Message 2 also includes one MLO Link KDE per active link. Each MLO Link KDE has a Link ID (0, 1, 2 for 2.4 / 5 / 6 GHz typically), RSNE / RSNXE info, and the per-link MAC address. This tells the AP "these are the links I want active under this MLD."

After Message 3, where per-link GTK / IGTK / BIGTK arrive, the client installs the single PTK once and the per-link group keys once each. Unicast frames between this AP and client on any link use the same PTK; broadcasts on Link 0 use Link 0's GTK; broadcasts on Link 1 use Link 1's GTK; etc.

EMLMR PN-space sharing. Under Enhanced Multi-Link Multi-Radio, the single PTK at MLD level is paired with a SHARED packet-number space across all simultaneously-active links. Firmware must synchronize PN updates across the radio chain. If it does not, replay-counter desync surfaces on one link while the others continue normally, both encrypted with the same PTK. Wireshark exposure: wlan.ccmp.pn across frames on the same TID.

KCK2 / KEK2 with GCMP-256. WPA3 with GCMP-256 + SAE-PT + 256-bit AKM produces a 512-bit PTK split as KCK2 (24 bytes) + KEK2 (32 bytes) + TK. MIC field in EAPOL frames extends to 32 bytes (HMAC-SHA-384) instead of 16 bytes. Many MLO deployments in 2026 still use CCMP-128 with the 384-bit PTK; the GCMP-256 + MLO combination is correct per spec but uncommon in shipped firmware.

Link recovery via Group Key Handshake. When one link fails and recovers, the AP refreshes that link's GTK via the 2-way Group Key Handshake (M5 / M6, also called the EAPOL-Key Group exchange). PTK is untouched. PCAP signature: standalone EAPOL-Key Group message with Key Type = 0, no SNonce, MLO GTK KDE present for the recovered Link ID. Confusingly similar to a re-key but does not regenerate the PTK.

Beacon Protection per link. Each link's BIGTK protects that link's beacons independently. A forged beacon advertising malicious parameters on Link 0 (e.g., a channel-switch to a jammed channel) fails MIC verification at clients holding Link 0's BIGTK and is dropped. The same client on Link 1 continues normally. Wi-Fi 7 mandates Beacon Protection; many Wi-Fi 6E APs already implement it.

R-TWT interaction with EAPOL in MLO. Restricted TWT can be scheduled per link in MLO. EAPOL frames during the MLO 4-way handshake contend for airtime normally on whichever link the handshake runs on. In a heavily R-TWT-scheduled BSS, M3 retries can queue behind R-TWT-protected traffic. Vendor mitigation varies; some firmware maps EAPOL to a high-priority Access Category to bypass R-TWT queuing.

Wireshark MLO handshake forensics. eapol && wlan.eht.multi_link filters MLO handshake traffic, wlan_rsna_eapol.keydes.data.type == 16 finds MLO GTK KDE in M3, wlan_rsna_eapol.keydes.data.type == 15 finds MLO Link KDE in M2, wlan_rsna_eapol.keydes.data.type == 3 finds MAC Address KDE, wlan.eht.multi_link.control.type == 0 identifies Basic Multi-Link element.