linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Cc: "linville@tuxdriver.com" <linville@tuxdriver.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] cfg80211: Removed warning from cfg80211_send_rx_auth
Date: Thu, 27 May 2010 11:27:22 +0200	[thread overview]
Message-ID: <1274952442.3669.28.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <1274950081.20619.18.camel@paavo-desktop>

On Thu, 2010-05-27 at 11:48 +0300, Teemu Paasikivi wrote:
> On Wed, 2010-05-26 at 13:21 +0200, ext Johannes Berg wrote:
> > On Wed, 2010-05-26 at 13:43 +0300, Teemu Paasikivi wrote:
> > > In cfg80211_send_rx_auth function there was a warning if bssid of the received
> > > authentication message was not found from the authtry_bsses table.
> > > 
> > > During the beginning of the authentication there is a small time window, when
> > > handling of the received deauthentication message can cause information
> > > for the access point to be removed from the authtry_bsses table before
> > > authentication response is received. This triggers the warning. This has
> > > been seen happening with several access points occasionally. At least
> > > one of those (Asus) has been seen to send spurious deauthentication
> > > messages after deauthentication. Possibly this warning could be triggered also
> > > by forged deauthentication messages sent at a correct time.
> > 
> > This doesn't seem right. Why is mac80211 not preventing those messages
> > from bubbling up in that case?
> > 
> > FWIW, this check is there for a reason -- we want to avoid telling
> > userspace twice that we disconnected from a given AP, and we shouldn't
> > be processing it anyway.

> Normally, when the stack in the idle state, or connected to other access
> point, those deauth messages doesn't cause a problem. The problem arises
> if that spurious deauth message is received at the right moment, when
> authentication to the access point has been started but response is not
> yet received. If I'm correct in that the deauthentication message from
> the AP during authentication is legal, this would be quite hard to
> filter out.

Yes .. I understand the scenario. You don't want to filter it out, you
want to abort the authentication so you kill the work for it and never
send the timeout to cfg80211.

johannes


  reply	other threads:[~2010-05-27  9:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-26 10:43 [PATCH] cfg80211: Removed warning from cfg80211_send_rx_auth Teemu Paasikivi
2010-05-26 11:21 ` Johannes Berg
2010-05-27  8:48   ` Teemu Paasikivi
2010-05-27  9:27     ` Johannes Berg [this message]
2010-05-28  6:55       ` Teemu Paasikivi
2010-05-28  8:02         ` Johannes Berg

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=1274952442.3669.28.camel@jlt3.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=ext-teemu.3.paasikivi@nokia.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.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).