On Wed, 2018-08-15 at 00:54 -0400, Mathy Vanhoef wrote: > > An easier alternative might be to push ieee80211_process_sa_query_req() > > to after ieee80211_rx_h_userspace_mgmt() so it won't see the frames if > > userspace claimed them, but I'm not sure how that works in AP mode where > > hostapd claims all frames - though I guess these aren't relevant in AP > > mode? > > > > However, then obviously wpa_s has to be able to handle them if OCV isn't > > included, which I haven't checked. It probably should be able to anyway > > though, since the frame might include other elements that aren't OCV, > > causing the kernel to punt it to wpa_s. > > SA Query request frames are also relevant in AP mode. They are fully > handled by hostapd currently. OK. But I see that they've never been handled by the kernel there - we check and do only in STATION mode. > With the OCV patch, wpa_s will also be able to handle SA Query requests > that don't contain the OCI element. So if userspace registered SA Query > request frames, it makes sense to send *all* SA Query requests to > userspace. Additionally, older versions of wpa_s won't register SA > Query request frames, meaning the kernel will still handle them, and > hence everything will still work normally. Right, good. > So to me, it make sense to only let the kernel reply to SA Query > requests when operating in station mode *and* when the userspace didn't > register SA Query frames. In that case, I suppose we can send a SA > Query response as is done currently, i.e., any payload in the SA Query > request is ignored? Sure, I think that's fair. So basically that means we can just move the handling of SA query request to *after* userspace redirection - in anything but station mode nothing changes (hostapd asks for all action frames but handles this one and we don't), and without changes to wpa_s in station mode also nothing changes since it won't ask for the frame, and if it does ask for it then it can as well handle all ... johannes
