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/9/2026 4:47 PM, Michael Pfeifroth wrote:
> 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".

Thanks for checking with the commit.

> 
> 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.

No, the EAPOL packet Tx handling remain between those firmware binaries.

> 
>    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?
> 

We do not observe this issue in our local setup. This behavior needs to be root-caused.



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

Sure, the below logs and configurations might be helpful for further analysis.

- dmesg output with ath12k debug_mask=0x6000
- dp stats output before and after the issue:
	cat /sys/kernel/debug/ath12k/<pci-bus_id>/device_dp_stats
- hostapd configuration in case this helps with the internal issue reproduction
- hostapd logs
- OTA Sniffer capture, if possible.


May be continue the debugging in a Bugzilla tracker for this issue?

Vasanth