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

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

[Vasanthakumar Thiagarajan]

On 9/4/2026 1:32 PM, Michael Pfeifroth wrote:
> 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.

Worth trying with commit 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e33f8acd837420160ea088160d8648a3db54c3b, 
if it is not part of your image already.

Vasanth

Re: 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]

On 9/8/2026 9:59 PM, Vasanthakumar Thiagarajan wrote:
> Worth trying with commit
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e33f8acd837420160ea088160d8648a3db54c3b,
> if it is not part of your image already.

Thanks for the pointer. I backported 1e33f8acd837 ("wifi: ath12k: fix
encrypted EAPOL TX in encap offload mode") onto my tree (backports-based,
single-file dp_tx.c); it builds and loads cleanly. Unfortunately it does
not fix the symptom I reported - the 4-way handshake still times out with
reason 15 and hostapd still logs "did not Ack EAPOL-Key frame".

Looking at the commit, I think it addresses a different EAPOL case than
the one that fails here:

  - 1e33f8ac only re-routes EAPOL frames that carry ATH12K_SKB_CIPHER_SET,
    i.e. *encrypted* EAPOL. On an established link that is the GTK rekey
    (group-key handshake), which happens after the pairwise keys are
    already installed.

  - The frame that fails in my case is EAPOL msg 1/4 of the *initial*
    4-way handshake. It is sent to a not-yet-authorized station before any
    key exists, so it is *unencrypted* and has no cipher set. It therefore
    still takes the unchanged is_diff_encap / TO_FW RAW exception path in
    ath12k_dp_tx() - exactly the path the 1.6 firmware appears to drop - so
    1e33f8ac leaves it untouched.

So the commit fixes the rekey EAPOL, but the initial handshake never gets
that far. Test details unchanged from my original report: QCN9274 hw2.0,
firmware WLAN.WBE.1.6-01243 (the latest published in linux-firmware
ath12k/QCN9274/hw2.0), AP mode WPA2-PSK/WPA3-SAE.

One thing I noticed: the commit's Tested-on tag is WLAN.WBE.1.6-01270,
which is newer than anything currently in linux-firmware (01243 is the
tip). Two questions:

  1. Does 01270 also change the firmware handling of the unencrypted
     pre-authorization EAPOL on the encap-exception path (i.e. would it fix
     the initial 4-way handshake, not just rekey)? And is 01270 planned to
     be published to linux-firmware? I can't reproduce your test setup
     without it.

  2. If the initial-handshake fix is expected to be driver-side, should
     ath12k also force the pre-authorization (unencrypted) EAPOL onto the
     native-WiFi path when ETH TX-encap offload is active - i.e. extend the
     handling to the is_diff_encap case, not only the cipher-set case?

Happy to provide full hostapd -dd logs and tx-path traces, or to test a
firmware/driver fix.

Thanks,
Michael Pfeifroth