Re: [PATCH wireless-next v2] wifi: mac80211: Fix AAD/Nonce computation for management frames with MLO

[Sai Pratyusha Magam <sai.magam@oss.qualcomm.com>]

On 2/9/2026 4:57 PM, Johannes Berg wrote:
> Hi,
> 
> So that looks like a huge improvement to me, nice! :-)
> 
> On Sun, 2026-02-08 at 13:48 +0530, Sai Pratyusha Magam wrote:
>> The hybrid way of having both HW/driver based crypto for certain frames
>> and SW crypto for others require that the fast-xmit path be skipped
>> when the above mentioned key flag is set, since data frames still rely
>> on software based crypto
> 
> I can understand this sentence in the sense of "A => B", and it
> describes why B follows from A, but ... why do you even need A? I.e. why
> do you want to do this for management frames only, it seems the encrypt
> function and having hwsim worry about it should work just as well for
> data frames?
>

> If I restrict hwsim [1] to only pairwise and CCMP/GCMP (clearly it
> doesn't handle TKIP due to Michael MIC, WEP is irrelevant, BIGTK isn't
> handled in hwsim), then it mostly works without all of that extra logic
> for me for the tests. Maybe need to think about IGTK here though, some
> tests are still failing.
> 
> [1] https://p.sipsolutions.net/d101bc31582cadcf.txt
>
Hi Johannes, Thank you for [1], yes the extra logic I had added 
(IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD) to prevent offload for 
AES-CMAC/AES-GMAC, i.e, MMIE addition for beacons(BIGTK) and broadcast 
robust management frames(IGTK) and for WEP/TKIP cases was not needed and 
the correct return value in the set_key ops was all that was needed to 
selectively offload encryption for CCMP/GCMP. I missed that.

Today, I tried with [1] , removed the redundant logic around the 
additional key flag this patch 
introduced(IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD) and data tx 
encryption offload, i.e ieee80211_encrypt_tx_skb() before address
translation.

I was able to pass the existing hwsim test cases that include test cases 
for beacon protection, broadcast robust mgmt, WEP/TKIP, unicast/bcast 
data and encrypted Assoc (EPP)




> 
> But if we do that (even if I don't like it, I'd rather fix the remaining
> issues), then you need to document reason for it.
> 
sorry, I did not follow this?

> johannes