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 <micpf@westermo.com>]

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