On Thu, 2011-01-27 at 02:20 +0200, Jouni Malinen wrote: > On Wed, Jan 26, 2011 at 11:08:39PM +0100, Johannes Berg wrote: > > 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? > > From the correctness view point, the STA entry would need to be enabled > (added/marked associated) at the moment the ACK frame is received. Since > we do some internal processing between kernel and user space, there is > obviously some latency involved. The most correct mechanism would be to > make hostapd add a not-associated-STA entry before sending association > response with status code 0 and request mac80211 to mark it associated > automatically on TX status report (showing success) from the driver. > However, for practical purposes, that may be too complex and doing what > you describe above is likely good enough. It's possible to do that as well -- but do we want to change any of this? It might be good, but it's mostly a hostapd change I think? 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