Skip to content

wifi: mt76: mt7996: fix FT-SAE by adding BIP batch key handling#1071

Open
gusbourg wants to merge 1 commit intoopenwrt:masterfrom
gusbourg:fix-ft-sae-bip-key-handling
Open

wifi: mt76: mt7996: fix FT-SAE by adding BIP batch key handling#1071
gusbourg wants to merge 1 commit intoopenwrt:masterfrom
gusbourg:fix-ft-sae-bip-key-handling

Conversation

@gusbourg
Copy link
Copy Markdown

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

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

FS#4201 - Broken 802.11r roaming if 802.11w is enabled (WPA3 or WPA2+802.11w)

1 participant