Return-path: Received: from ey-out-2122.google.com ([74.125.78.26]:52147 "EHLO ey-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752813AbYIBNEj (ORCPT ); Tue, 2 Sep 2008 09:04:39 -0400 Received: by ey-out-2122.google.com with SMTP id 6so1170720eyi.37 for ; Tue, 02 Sep 2008 06:04:36 -0700 (PDT) Date: Tue, 2 Sep 2008 16:04:31 +0300 From: "Michael S. Tsirkin" To: Johannes Berg Cc: Zhu Yi , "Rafael J. Wysocki" , LKML , reinette.chatre@intel.com, linux-wireless@vger.kernel.org, Jan-Espen Pettersen , "John W. Linville" Subject: Re: new: regression iwl3945/mac80211 endless after suspend associate/deassociate loop Message-ID: <20080902130429.GB19172@google.com> (sfid-20080902_150501_409380_08323539) References: <20080901160658.GA11063@google.com> <1220319536.28282.128.camel@debian.sh.intel.com> <4b0be9b641de902cb7de4ad50686f6e1.squirrel@secure.sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <4b0be9b641de902cb7de4ad50686f6e1.squirrel@secure.sipsolutions.net> Sender: linux-wireless-owner@vger.kernel.org List-ID: 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 and contributors But it happens to work fine without 8ab65b03b7893da4a49009e7e356e36e27b0c407. So yes, this could be some assumption that wpa_supplicant makes and that fails now. I guess I will try the latest version from source and report.