From: Dan Williams <dcbw@redhat.com>
To: Michael Buesch <mb@bu3sch.de>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
linville@tuxdriver.com, netdev@vger.kernel.org
Subject: Re: [PATCH] softmac: Fix WX and association related races
Date: Thu, 28 Sep 2006 10:19:34 -0400 [thread overview]
Message-ID: <1159453174.2642.8.camel@localhost.localdomain> (raw)
In-Reply-To: <200609281455.53763.mb@bu3sch.de>
On Thu, 2006-09-28 at 14:55 +0200, Michael Buesch wrote:
> On Thursday 28 September 2006 06:09, Larry Finger wrote:
> > Michael Buesch wrote:
> > > On Wednesday 27 September 2006 18:18, Larry Finger wrote:
> > >> Michael Buesch wrote:
> > >>> This fixes some race conditions in the WirelessExtension
> > >>> handling and association handling code.
> > >>>
> > >>> Signed-off-by: Michael Buesch <mb@bu3sch.de>
> > >>>
> > >>> ---
> > >> This patch doesn't apply.
> > >
> > > Oh, linville merged stuff on the 25th. That's the day I updated
> > > my tree to do this patch. But seems like I did it just before
> > > the merge.
> > > Who could suspect that linville merges something. :D
> > > *me runs away*
> > >
> > > Anyway. Here's an updated patch.
> >
> > NACK this version. It applied correctly, but introduced a new problem. My device occasionally gets
> > deauthentication messages from my AP.Preciously, it would do a scan or two, and then reauthenticate.
> > After your patch was applied, it never stops scanning.
>
> Oh, well... It's impossible to completely fix softmac race issues.
> I am _not_ going to rewrite huge parts of softmac to get locking
> working. If you want this to be fixed, please hack up a solution by
> yourself. I'm really not going to do more work on softmac. This
> has various reasons. 1) I cannot reproduce all these bugs I'm hunting
> 2) Time is spent better at d80211 or other projects.
>
> But to debug the problem:
> Why do you get deauth messages? Broken AP?
> I'd say that it's _correct_ behaviour to stop working
> after getting a deauth ;). wpa_supplicant is responsible to re-auth.
I'd buy that argument. When the driver gets the deauth message,
shouldn't it be sending an IWAP 00:00:00:00:00:00 wireless event to
userspace? That would cause a tool like wpa_supplicant (or NM) to
attempt reauth/reassoc anyway, based on their own policy.
"Stations may send Disassociation or Deauthentication frames in response
to traffic when the sender has not properly joined the network." (802.11
Wireless Networks)
What's the value of the Reason Code received in the deauth frame? That
will give a clue as to why the AP is rejecting you:
0 Reserved; unused
1 Unspecified
2 Prior authentication is not valid
3 Station has left the basic service area or extended service area
and is deauthenticated
4 Inactivity timer expired and station was disassociated
5 Disassociated due to insufficient resources at the access point
6 Incorrect frame type or subtype received from unauthenticated station
7 Incorrect frame type or subtype received from unassociated station
8 Station has left the basic service area or extended service area and is
disassociated
9 Association or reassociation requested before authentication is complete
10 Reserved; unused
> Why doesn't it re-auth? Or does it do and it just doesn't work as
> expected?
It would be interesting to know what state the driver's state machine is
in when it gets this message. Does the driver think it's authenticated?
Does the AP think the same thing?
Dan
next prev parent reply other threads:[~2006-09-28 14:18 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-27 15:26 [PATCH] softmac: Fix WX and association related races Michael Buesch
2006-09-27 16:18 ` Larry Finger
2006-09-27 17:50 ` Michael Buesch
2006-09-27 21:11 ` Christian
2006-09-27 21:21 ` Christian
2006-09-27 22:23 ` Benjamin Herrenschmidt
2006-09-28 0:43 ` Larry Finger
2006-09-28 1:04 ` Benjamin Herrenschmidt
2006-09-28 4:09 ` Larry Finger
2006-09-28 12:55 ` Michael Buesch
2006-09-28 14:19 ` Dan Williams [this message]
2006-09-28 14:27 ` Johannes Berg
2006-09-28 14:37 ` Dan Williams
2006-09-28 14:43 ` Michael Buesch
2006-09-28 14:52 ` Dan Williams
2006-09-28 15:13 ` Michael Buesch
2006-09-28 17:33 ` Jouni Malinen
2006-09-28 15:16 ` Larry Finger
2006-09-28 15:29 ` Michael Buesch
2006-09-28 15:35 ` Michael Wu
2006-09-28 15:52 ` Larry Finger
2006-09-28 16:31 ` Jason Lunz
2006-09-28 17:04 ` Larry Finger
2006-09-28 17:14 ` Michael Buesch
2006-09-28 17:40 ` Larry Finger
2006-09-28 14:43 ` Johannes Berg
2006-09-27 22:20 ` Benjamin Herrenschmidt
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=1159453174.2642.8.camel@localhost.localdomain \
--to=dcbw@redhat.com \
--cc=Larry.Finger@lwfinger.net \
--cc=linville@tuxdriver.com \
--cc=mb@bu3sch.de \
--cc=netdev@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 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).