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: - sta sends assoc - hostapd sends response - when assoc response ACK is received, hostapd sets state to assoc - incoming frame - hostapd adds STA to mac80211 then in this case mac80211 will pass the incoming frame up to hostapd, and not to the network stack, but hostapd knows that it's a good frame and won't kick out the station The only difference is that with your firmware the kicking out is done by the firmware, not hostapd, so it actually gets kicked out rather than the frame being dropped. So ... the race exists even without the firmware, it just has less severe consequences. 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? 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
