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

[Johannes Berg <johannes@sipsolutions.net>]

Hi,

Sorry I didn't get back to this yesterday. I see you now just sent
another patch.

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

I guess that makes sense, fair enough.

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

It's actually also something wpa_s could check, but I suppose it's
plausible that non-wpa_s observers of these events might be interested.

> In the wireless-next tip, there are already commits that combine both cfg80211
> and mac80211 changes together, 

True, but that's usually if the whole thing is small enough I guess?

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

I think in this case I might have just preferred to have the first
commit add *all* the infrastructure, and indicate that it's done for
assoc for the reasons above, and then have the second just be mac80211
to fill it?

Not super important though I guess.

johannes