Return-path: Received: from smtp.nokia.com ([192.100.122.230]:17874 "EHLO mgw-mx03.nokia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751946Ab0E0IzF (ORCPT ); Thu, 27 May 2010 04:55:05 -0400 Subject: Re: [PATCH] cfg80211: Removed warning from cfg80211_send_rx_auth From: Teemu Paasikivi To: ext Johannes Berg Cc: "linville@tuxdriver.com" , "linux-wireless@vger.kernel.org" In-Reply-To: <1274872877.3658.4.camel@jlt3.sipsolutions.net> References: <1274870625-19712-1-git-send-email-ext-teemu.3.paasikivi@nokia.com> <1274872877.3658.4.camel@jlt3.sipsolutions.net> Content-Type: text/plain Date: Thu, 27 May 2010 11:48:01 +0300 Message-Id: <1274950081.20619.18.camel@paavo-desktop> Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Wed, 2010-05-26 at 13:21 +0200, ext Johannes Berg wrote: > On Wed, 2010-05-26 at 13:43 +0300, Teemu Paasikivi wrote: > > In cfg80211_send_rx_auth function there was a warning if bssid of the received > > authentication message was not found from the authtry_bsses table. > > > > During the beginning of the authentication there is a small time window, when > > handling of the received deauthentication message can cause information > > for the access point to be removed from the authtry_bsses table before > > authentication response is received. This triggers the warning. This has > > been seen happening with several access points occasionally. At least > > one of those (Asus) has been seen to send spurious deauthentication > > messages after deauthentication. Possibly this warning could be triggered also > > by forged deauthentication messages sent at a correct time. > > This doesn't seem right. Why is mac80211 not preventing those messages > from bubbling up in that case? > > FWIW, this check is there for a reason -- we want to avoid telling > userspace twice that we disconnected from a given AP, and we shouldn't > be processing it anyway. > > johannes > Normally, when the stack in the idle state, or connected to other access point, those deauth messages doesn't cause a problem. The problem arises if that spurious deauth message is received at the right moment, when authentication to the access point has been started but response is not yet received. If I'm correct in that the deauthentication message from the AP during authentication is legal, this would be quite hard to filter out. Best regards, Teemu