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/14/2026 2:04 PM, Sebastian Gottschall wrote:
> 
> 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)

There is no known issues with encap/decap offloads in any of the data frame addressing
modes (addr-3/addr-4). Here as well, if you can share the above logs with 1.6 firmware in 
issue scenario, it will be helpful.


Vasanth