On Thu, Jan 27, 2011 at 00:08, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Thu, 2011-01-27 at 00:02 +0200, Arik Nemtsov wrote: > >> >> 2. The STA transmits something >> >> 3. The AP FW deauths the STA >> >> 4. hostapd adds the station, causing mac80211 to call add_sta(), which >> >> causes the FW to add the sta >> >> >> >> Then we have an endless loop of sta add/remove.. >> > >> > I'd wondered about that race condition before -- maybe hostapd should >> > add the station before sending the assoc complete. The race also exists >> > in practice with just mac80211, except it only leads to a dropped frame. >> >> Well it can still get dropped here. This just prevents the FW from >> de-authenticating the STA. > > No I mean the incoming frame would be dropped: In my previous email what I meant was - even with this patch for the FW (which allows the incoming packet through without the STA getting de-authed), the incoming frame can still get dropped by mac80211. The race always exists in mac80211/hostapd. > > If we add the station before the response frame's ACK is received, we > still have the race, and we need to delete if we don't get the ACK. If > we add the station before we send the assoc response we get rid of this > race, but also have to delete if we don't get the ACK. I guess that case > is actually nicer in some way since we would have allowed the station to > connect, so if spurious data frames go up because we don't get an ACK > from the station that's no big deal? > Maybe there's no need to delete the station even when no ACK is received? It will get disconnected after the idle timeout anyway. And it already passed authentication, so its not a DOS attack. (If that's what you meant as well then I agree) Arik -- 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
