> I also think we shouldn't necessarily punt too short or otherwise > malformed frames to userspace, what's the point? We currently > drop/ignore those, and can continue to do so afaict? Agreed, we should drop too short or malformed frames. > 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. 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. 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? Cheers, Mathy
