wifi: mt76: mt7996: fix FT-SAE by adding BIP batch key handling#1071
Open
gusbourg wants to merge 1 commit intoopenwrt:masterfrom
Open
wifi: mt76: mt7996: fix FT-SAE by adding BIP batch key handling#1071gusbourg wants to merge 1 commit intoopenwrt:masterfrom
gusbourg wants to merge 1 commit intoopenwrt:masterfrom
Conversation
mt7996's key installation path (mt7996_mcu_sta_key_tlv) installs BIP
keys individually, while the mt76_connac path used by mt7915 installs
them as a batch of two keys (AES_CCMP + BIP_CMAC_128). This causes
FT-SAE (802.11r with WPA3) to fail when the mt7996 is the target AP,
as the management frame protection keys are not properly paired with
the pairwise key during fast BSS transition.
The symptom is that hostapd completes the FT authentication
successfully but the driver fails to deliver the association response
to the client ("did not acknowledge association response"), causing
the client to fall back to full SAE re-authentication. This was
confirmed through extensive testing: FT-PSK (WPA2) works on mt7996,
FT-SAE works on mt7915 (which uses the connac BIP batch path), but
FT-SAE fails on mt7996.
The fix adds BIP_CMAC_128 batch mode handling to
mt7996_mcu_sta_key_tlv, matching the logic in
mt76_connac_mcu_sta_key_tlv:
- When BIP_CMAC_128 cipher is received, install two keys: the
previously-cached AES_CCMP key plus the BIP key
- When AES_CCMP cipher is received, cache it in the per-station
sta_key_conf for the subsequent BIP batch update
- Pass the existing but unused msta_link->bip field through the
key installation call chain
Tested on BananaPi BPI-R4 (MT7988 + BE14 WiFi module) with
ft_over_ds=1 and pmk_r1_push=1, achieving 100% FT-SAE success rate
across 2.4GHz, 5GHz, and 6GHz bands.
Fixes: openwrt/openwrt#9181
Signed-off-by: Gus Bourg <gus@bourg.net>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
mt7996's key installation path (mt7996_mcu_sta_key_tlv) installs BIP keys individually, while the mt76_connac path used by mt7915 installs them as a batch of two keys (AES_CCMP + BIP_CMAC_128). This causes FT-SAE (802.11r with WPA3) to fail when the mt7996 is the target AP, as the management frame protection keys are not properly paired with the pairwise key during fast BSS transition.
The symptom is that hostapd completes the FT authentication successfully but the driver fails to deliver the association response to the client ("did not acknowledge association response"), causing the client to fall back to full SAE re-authentication. This was confirmed through extensive testing: FT-PSK (WPA2) works on mt7996, FT-SAE works on mt7915 (which uses the connac BIP batch path), but FT-SAE fails on mt7996.
The fix adds BIP_CMAC_128 batch mode handling to
mt7996_mcu_sta_key_tlv, matching the logic in
mt76_connac_mcu_sta_key_tlv:
Tested on BananaPi BPI-R4 (MT7988 + BE14 WiFi module) with ft_over_ds=1 and pmk_r1_push=1, achieving 100% FT-SAE success rate across 2.4GHz, 5GHz, and 6GHz bands.
Fixes: openwrt/openwrt#9181