Re: [PATCH] softmac: Fix WX and association related races

[Dan Williams <dcbw@redhat.com>]

On Thu, 2006-09-28 at 16:43 +0200, Michael Buesch wrote:
> On Thursday 28 September 2006 16:37, Dan Williams wrote:
> > On Thu, 2006-09-28 at 16:27 +0200, Johannes Berg wrote:
> > > On Thu, 2006-09-28 at 10:19 -0400, Dan Williams wrote:
> > > 
> > > > 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?
> > > 
> > > I thought we did that since a long time now, didn't you actually develop
> > > the initial patch?
> > 
> > Yes, I think I did.  My point here wasn't that the driver is _not_
> > sending those messages (it almost certainly is), but what's _implied_ by
> > those messages.  Namely that, if you're using a tool like wpa_supplicant
> > and/or NM, when you get a deauth from the AP and send the IWAP event,
> > all bets are off because the tool will likely override whatever the
> > driver thinks its doing.
> > 
> > I'm somewhat ambiguous on just how much policy a driver should try to
> > enforce.  I guess I'm OK with reassociation with the _same_ credentials.
> > But what airo does with "auto_wep" is very nearly, if not completely,
> > crossing the line [1].  The real question is, how much should drivers
> > really do, and how much should they leave to userspace?
> 
> IMO a driver should implement absolutely _zero_ policy, as this
> is the only way to get the same (default) policy for different
> cards. A driver should _only_ provide generic events for
> userspace tools to make decisions.
> A "I got a deauth" event is really enough for userspace to
> know what to do.

As a counterpoint, does every developer _really_ want to run
wpa_supplicant just to use a WEP-encrypted connection where you may
occasionally get kicked off?

I think it's clear that with WPA, it's pretty nearly impossible to do
reauth/reassoc because you need a user-space supplicant, right?  But WEP
doesn't require any interaction other than the 2- or 4-stage handshake
for open or shared key, and that's already done in the driver.

I'd say that handling WEP reauth/reassoc in the driver is probably fine
[1] since many drivers already try to do this, but I believe it's
probably inappropriate for anything more than WEP.  It's probably also
impossible to do with any sort of more-than-WEP roaming, maybe even WEP
roaming.

Dan

[1] with a suitable timeout or #tries clamp so it doesn't try forever.
airo does the auto_wep thing twice before failing and sending IWAP
00:00:... I believe.

> > Dan
> > 
> > [1] if the auth mode (open or shared-key) doesn't work, airo schedules a
> > timer and bumps the auth mode to the other one automatically, and tries
> > reassociation.
> > 
> > 
> > 
>