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...
> 



The NL80211_ATTR_ASSOC_ENCRYPTED attribute targets NL80211_CMD_CONNECT, not
NL80211_CMD_ASSOCIATE, both are sent from cfg80211_rx_assoc_resp(), but
NL80211_CMD_CONNECT carries only IEs with no MAC frame headers for either
Request or Response.

The attribute is intended to indicate that the entire exchange was encrypted,
not just the Response. For the Response frame, checking ieee80211_has_protected()
is possible since the full frame is available in data->buf, but for the Request
frame only IEs are stored in ifmgd->assoc_req_ies, the MAC header is not preserved,
so I cannot check the Protected bit for the Request.

While an unencrypted Request paired with an encrypted Response is unlikely in practice,
we did not want to leave that gap, so I used the epp_peer flag. That said, if you think
checking the Protected bit on the Response frame alone is sufficient, we are fine with
that approach too.


> 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.



In the wireless-next tip, there are already commits that combine both cfg80211
and mac80211 changes together, so since the assoc_encrypted field addition in
cfg80211 and the mac80211 epp_peer lookup that sets it are tightly dependent on
each other, I kept them in the same commit. If you prefer them split into two
separate commits, I can do that. Will update the commit as well.



> 
> johannes