ath12k: QCN9274 WLAN.WBE.1.6 firmware drops pre-auth EAPOL in TX encap-offload mode (WPA 4-way handshake fails in AP mode)

ath12k: QCN9274 WLAN.WBE.1.6 firmware drops pre-auth EAPOL in TX encap-offload mode (WPA 4-way handshake fails in AP mode)

[Michael Pfeifroth]

Hi,

I'd like to report a firmware behaviour regression on QCN9274 that breaks
encrypted AP mode, and ask how you'd prefer to see it addressed upstream.

Hardware/platform: QCN9274 hw2.0, PCIe, on an NXP ls1046 (ARM64, little-endian).
Firmware: WLAN.WBE.1.6-01243 (QC_IMAGE_VERSION_STRING=WLAN.WBE.1.6-01243-
QCAHKSWPL_SILICONZ-1, fw_version 0x160484db), from linux-firmware
ath12k/QCN9274/hw2.0.
Driver: ath12k, current mainline / backports.

Symptom
-------
With WPA2-PSK or WPA3-SAE in AP mode, stations authenticate and associate,
but the 4-way handshake never completes: hostapd (-dd) reports "did not Ack
EAPOL-Key frame", the EAPOL-Key timeout retries exhaust, and the client is
deauthenticated with reason 15 (4-way handshake timeout). Open/unencrypted
APs work fine.

Analysis
--------
WLAN.WBE.1.6 advertises WMI_TLV_SERVICE_ETH_OFFLOAD, so ath12k enables
SUPPORTS_TX_ENCAP_OFFLOAD / SUPPORTS_RX_DECAP_OFFLOAD (commit d29591d5b52e)
and mac80211 switches the AP vdev to 802.3/Ethernet encapsulation. The
unencrypted EAPOL msg 1/4, sent to a still-unauthorized peer, then goes
through the RAW / TO_FW is_diff_encap exception path in ath12k_dp_tx().
Under 1.6 that frame is apparently never put on air - it is never acked.

The older WLAN.WBE.1.1.1 firmware does not advertise
WMI_TLV_SERVICE_ETH_OFFLOAD, uses the native-WiFi EAPOL path, and completes
the handshake. So the trigger is the firmware enabling ETH offload while
mishandling the encap-exception EAPOL path.

Workaround (local, not proposed for upstream)
----------------------------------------------
Not advertising HW encap/decap offload restores the native-WiFi EAPOL TX
path and makes WPA2/WPA3 work again; MLO / Wi-Fi 7 is unaffected (gated
separately on the firmware MLO feature IE). This obviously sacrifices
offload for everyone, so it isn't a real fix - hence this report.

Questions
---------
1. Is this a known issue with WLAN.WBE.1.6 on QCN9274? Is a firmware fix
   planned?
2. Should the driver special-case the pre-authorization EAPOL frame so it
   always uses the native-WiFi path even when ETH TX-encap offload is active?

Happy to provide full hostapd -dd logs, tx-path traces, or test firmware
fixes.

Thanks,
Michael Pfeifroth