[PATCH ath-next] wifi: ath12k: fix encrypted EAPOL TX in encap offload mode

[Jeff Johnson]

On 7/30/2026 3:02 AM, Sebastian Gottschall wrote:
> 
> Am 29.07.2026 um 19:17 schrieb Reshma Immaculate Rajkumar:
>> When a vif operates with IEEE80211_OFFLOAD_ENCAP_ENABLED,
>> mac80211 delivers EAPOL frames to ath12k in native-WiFi format.
>>
>> Unencrypted EAPOL frames used during the initial 4-way
>> handshake are already handled through the existing
>> is_diff_encap path. However, EAPOL frames transmitted during
>> GTK rekeying carry ATH12K_SKB_CIPHER_SET and continue through
>> the normal native-WiFi transmit path.
>>
>> Firmware encryption requires RAW frames with cipher-specific IV and ICV
>> fields correctly provisioned in the skb. Passing encrypted EAPOL frames
>> in native-WiFi format results in incorrect IV provisioning, leading to
>> an invalid ICV and frame drop.
>>
>> Fix this by detecting the EAPOL frames that need HW encryption and
>> converting them to firmware-encrypted RAW frames before transmission.
>> Reserve IV space after the MAC header, append ICV space at the tail,
>> select the appropriate firmware encryption type and request
>> firmware-side encryption.
>>
>> Introduce ath12k_dp_tx_crypto_iv_len() and ath12k_dp_tx_crypto_icv_len()
>> helpers in the TX path to obtain cipher-specific IV and ICV lengths.
>>
>> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01270-QCAHKSWPL_SILICONZ-1
> you mention WLAN.WBE.1.6-01270-QCAHKSWPL_SILICONZ-1 but this firmware 
> isnt available for public. i tested it with wds frames enabled and still 
> have problems with the current available version (01243)

This has fixed an issue in our testbed, and Reshma verified it with the
upstream firmware as well, so I've asked her to reach out directly to you to
debug your failure.

/jeff