Re: [PATCH wireless-next 2/2] wifi: cfg80211/mac80211: extend cfg80211_rx_assoc_resp_data() for assoc encryption

[Kavita Kavita <kavita.kavita@oss.qualcomm.com>]

On 4/28/2026 1:08 PM, Johannes Berg wrote:
> On Mon, 2026-04-27 at 20:37 +0530, Kavita Kavita wrote:
>> Extend cfg80211_rx_assoc_resp_data with a new assoc_encrypted field to
>> indicate if the (re)association exchange is encrypted.
>>
>> Currently, when epp_peer flag is set, unprotected (Re)Association
>> Request/Response frames are dropped. This ensures that by the time
>> the (Re)Association Response is processed, the entire association
>> exchange is encrypted over the air.
>>
>> Set assoc_encrypted in cfg80211_rx_assoc_resp_data based on epp_peer
>> flag when processing the (Re)Association Response.
> 
> I don't quite see how this is necessary, even in nl80211_send_rx_assoc()
> the whole frame, including header and protected bit, is available. Why
> does this need mac80211 involvement? 

One could ask why it's needed *at
> all* when userspace already gets the frame and should probably process
> the frame RX preferably over the connect result indication...
>



If I correctly understand your point, you meant that when both NL80211_CMD_ASSOCIATE
and NL80211_CMD_CONNECT are indicated (mac80211/SME-in-supplicant case), NL80211_CMD_ASSOCIATE
will always be processed which has the full frame, then the point is valid. However, since
we are sending the NL80211_CMD_CONNECT result, I thought of passing assoc_encrypted there
as well for completeness. At present, there is no use of passing assoc_encrypted in this case,
so we can drop this patch.


 
> If this is needed for some reason please outline it in the commit
> message, and reshuffle the code to properly split between cfg80211 and
> mac80211 in the commits.
> 
> johannes