Re: new: regression iwl3945/mac80211 endless after suspendassociate/deassociate loop

[Dan Williams]

On Tue, 2008-09-02 at 17:58 +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 02, 2008 at 09:30:01AM -0400, Dan Williams wrote:
> > On Tue, 2008-09-02 at 16:04 +0300, Michael S. Tsirkin wrote:
> > > On Tue, Sep 02, 2008 at 08:10:09AM +0200, Johannes Berg wrote:
> > > > Zhu Yi wrote:
> > > > > On Mon, 2008-09-01 at 19:07 +0300, Michael S. Tsirkin wrote:
> > > > >> [16482.909453] eth1: associate with AP XX:XX:XX:XX:XX:XX
> > > > >> [16482.918553] eth1: RX ReassocResp from XX:XX:XX:XX:XX:XX
> > > > >> (capab=0x411 status=0 aid=1)
> > > > >> [16482.918564] eth1: associated
> > > > >> [16492.920224] eth1: disassociating by local choice (reason=3)
> > > > >> [16492.920986] eth1: disassociating by local choice (reason=3)
> > > > >
> > > > > It is exactly 10 seconds the local STA sends the deauth_leaving frame
> > > > > before associated everytime. I wonder if it is the timeout for some
> > > > > wireless config tools. NM?
> > > > 
> > > > "by local choice" means wext requested this, not a kernel bug.
> > > > 
> > > > johannes
> > > 
> > > Sure, it's wpa_supplicant in ubuntu gutsy doing it.
> > > 
> > > $wpa_supplicant -version
> > >  wpa_supplicant v0.5.8
> > >  Copyright (c) 2003-2007, Jouni Malinen <j@xxxxx> and contributors
> > > 
> > > But it happens to work fine without 8ab65b03b7893da4a49009e7e356e36e27b0c407.
> > 
> > That's really odd; that patch (the don't-send-empty-extended-rates-IE
> > patch) shouldn't have anything to do with this behavior, if it did you
> > wouldn't get associated to the AP in the first place I think.  You're
> > 100% sure that this patch is causing the problem?
> 
> No, not sure. But reverting it seems to have helped.
> And there does not seem to be anything else relevant between rc4 and
> rc5.
> 
> >  Can you post the
> > output of running wpa_supplicant with the "-dddt" flags
> 
> I put up a (sanitized) -dd output here
> http://bugzilla.kernel.org/show_bug.cgi?id=11476

Logs seem to indicate a normal failure of the 4 way handshake; are you
sure your PSK is correct?  It actually looks like the AP doesn't ever
get message #2 from your machine, and just retransmits message #1 of the
handshake.  I'm pretty sure that if
8ab65b03b7893da4a49009e7e356e36e27b0c407 had anything to do with it, you
wouldn't be getting this far and the AP would have denied association in
the first place.

To me this looks like the 4-way handshake is going wrong and either the
supplicant is killing the connection or the AP is terminating the
connection due to that.  This doesn't rule out driver problems but we'd
need better analysis of the wpa_supplicant logs (be smarter people than
I) to figure out whether I'm on the right track or not.

Dan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/