Re: WPA connection/reconnection timeouts

[Dan Williams <dcbw redhat com>]

On Mon, 2007-05-07 at 17:48 +0200, Fionn Behrens wrote:
> On 06.05.2007, 21:50 -0400 Dan Williams wrote these lines:
> 
> > > The patch allows setting the timeout at runtime via nm-tool. Unfortunately 
> > > it seems to have gone totally unnoticed by now, despite the fact that the 
> > > bug appears to be linked to upstream (bugzilla.gnome.org).
> > 
> > It's not unnoticed, it's just the wrong fix for the problem and
> > therefore won't get upstream into NetworkManager.
> 
> Your exceptionally kindly phrased refusal is surpassed only by its
> wealth of explanation. Thank you!
> But with regard to how much time this took, I probably should feel
> honored to finally have gotten some feedback at all.

Sorry, I had assumed that people involved in the discussion had read the
archives when this topic first came up about a month or two ago.

The core of the problem is that this is may be a driver issue.  There's
no reason why re-association should take more than a 5 - 10 seconds at
most.  Papering over the issue in NetworkManager without investigating
why the driver is dropping association for more than 8 seconds is just
the wrong answer.

Without a lot more investigation into why the drivers are having
problems, and why only _certain_ drivers are having problems, the patch
is incorrect.  Patches that are not investigated are not going to get
applied just like that.

I'd like to see driver traces from madwifi and ipw2200 that indicate why
the association was dropped, and what the card is doing to achieve
re-association during those 10 - 20 seconds.  Remember, during the 10 -
20 seconds, the driver should _not_ be able to pass traffic if it's
really disassociated from the AP.

If the driver is actually associated to the AP, then it needs to report
that correctly via WEXT, which is the noticed by wpa_supplicant, which
is then noticed by NetworkManager.  So we need to verify that the driver
is doing the right thing first, before crying wolf and patching
NetworkManager for something that in reality may not actually be
required.  A clear picture of the issue is required.

Remember, when you encounter errant behavior, there's a lot more in the
stack than just NetworkManager, and that includes both wpa_supplicant
and the drivers.  Historically, drivers have been quite inconsistent and
buggy.  That's not to say that NM is bug-free at all, just that many
behavioral problems like this can be traced back to drivers behaving
badly.

Dan

> Please share with me your wisdom on what makes the patch not preferable
> to the current fixed-value non-solution and how it could be done better
> so I might be able to achieve your blessing eventually.
> 
> humbly yours,
> 		Fionn