On Thu, 2010-05-27 at 11:27 +0200, ext Johannes Berg wrote: > On Thu, 2010-05-27 at 11:48 +0300, Teemu Paasikivi wrote: > > 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. > > > 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. > > Yes .. I understand the scenario. You don't want to filter it out, you > want to abort the authentication so you kill the work for it and never > send the timeout to cfg80211. > > johannes > Isn't that already done? Aborting the authentication, I mean. The warning is triggered by the authentication response in the cfg80211_send_rx_auth function. Removal of the warning would keep logs clean. I suppose that in the case where wdev->sme_state != CFG80211_SME_CONNECTING we could just bail out from the cfg80211_send_rx_auth function instead of removing the warning. Teemu -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
