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

[Sebastian Gottschall]

Am 14.09.2026 um 09:46 schrieb 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

just as notice. it have a similar issue but only with wds 4addr enabled. 
(which btw does not work at all with 1.7 firmware, but only with 1.6 but 
with crypto enabled i have to disable offloading on 1.6 to get it to work)


Sebastian