From: Johannes Berg <johannes@sipsolutions.net>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
"hostap@lists.shmoo.com" <hostap@lists.shmoo.com>
Subject: Re: Association race when acting as AP?
Date: Thu, 02 Jul 2015 13:41:34 +0200 [thread overview]
Message-ID: <1435837294.2285.10.camel@sipsolutions.net> (raw)
In-Reply-To: <CA+BoTQk1YT-CD2sA3Ev9v7+H2hV=OszawLFg9e4FehFoaPkV7A@mail.gmail.com> (sfid-20150702_122838_890623_0571CDEC)
On Thu, 2015-07-02 at 12:28 +0200, Michal Kazior wrote:
> > Ultimately, depending on the nl80211 capabilities, the station
> > should
> > in fact be added (as unauthenticated) before even sending the
> > authentication response frame, and then stepping through the stages
> > appropriately.
>
> While I think it does make sense (I thought of this too, sounds
> desirable) I think it wouldn't solve the race problem entirely. The
> station might no longer be rejected with Deauth but may end up
> confusing AP's internal/offloaded STA powersave state depending on
> implementation detail (what do you do when you receive NullFunc from
> a
> station that you don't know assoc id of or isn't fully initialized as
> associated?).
We'd send a deauth with "class 3 frame from unassociated STA" reason :)
> I.e. station should be transitioned to Assoc state
> before sending the Assoc Resp frame.
Yeah, I guess that's still true, but it doesn't preclude adding the
station before auth response and sending an auth response depending on
whether it could be added; perhaps we need to set it to authenticated
just before sending the frame as well though.
johannes
next prev parent reply other threads:[~2015-07-02 11:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CA+BoTQm==AM3F2Fxq6T_+uY+jq0yXc9JHFT0iwpe2XJrmxkSsg@mail.gmail.com>
2015-07-02 8:38 ` Association race when acting as AP? Johannes Berg
2015-07-02 10:28 ` Michal Kazior
2015-07-02 11:41 ` Johannes Berg [this message]
[not found] ` <CAB3XZEf4jC6-au4KQ7SrBtUAyq1LmOqFrT_PLrDZ8ER8ZpR1SA@mail.gmail.com>
2015-07-02 10:39 ` Michal Kazior
2015-07-02 12:45 ` Eliad Peller
2015-07-07 15:00 ` Jouni Malinen
2015-07-09 12:42 ` Michal Kazior
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=1435837294.2285.10.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=hostap@lists.shmoo.com \
--cc=linux-wireless@vger.kernel.org \
--cc=michal.kazior@tieto.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).