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 -- 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
