All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
Cc: linux-wireless@vger.kernel.org, Jouni Malinen <j@w1.fi>
Subject: Re: [PATCH] mac80211: ignore SA Query Requests with unknown payload data
Date: Wed, 15 Aug 2018 11:16:20 +0200	[thread overview]
Message-ID: <1534324580.3547.33.camel@sipsolutions.net> (raw)
In-Reply-To: <20180815005419.2e73c068@cs.kuleuven.be>

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

      reply	other threads:[~2018-08-15 12:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-06 22:48 [PATCH] mac80211: ignore SA Query Requests with unknown payload data Mathy Vanhoef
2018-08-14 11:11 ` Johannes Berg
2018-08-14 11:16   ` Johannes Berg
2018-08-14 11:17     ` Johannes Berg
2018-08-15  4:54       ` Mathy Vanhoef
2018-08-15  9:16         ` Johannes Berg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1534324580.3547.33.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=Mathy.Vanhoef@cs.kuleuven.be \
    --cc=j@w1.fi \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.