On Sun, 2012-04-08 at 15:49 +0300, Eliad Peller wrote: > > Completely untested so far, just wanted to see what > > everybody thinks. I'll need to work on the hostapd > > patch as well, but I think TI had something there to > > fix a race which I need to look into. > > > The patch looks good -- i agree it's better to add the station as soon > as possible. > > in our internal hostap tree, we use the following patches: > https://github.com/TI-OpenLink/hostap/commit/44e8fd28f9b2fc8da9c6f58a2731b4ffa65bc396 > (https://github.com/TI-OpenLink/hostap/commit/bf21f3fe7541cd17b7b92aaf6bf06a00e9ec28bb) > > These patches handle the race in which the EAPOL Start from the client > comes before the association response tx result, causing the EAPOL to > get dropped. Ok, cool, thanks for the patches -- I couldn't quite remember what the race was :) > The first patch simply adds the station before sending the association > response. I guess that with the suggested patch we'll just have to set > the ASSOC state (before sending assoc response) instead of adding the > station (which will be done before sending auth response, i guess). Yes, my plan was adding the station before sending the auth response, which gives better behaviour in case the driver already rejects the station at that point, and move it to auth for the auth frame ack maybe or when the assoc frame comes in, etc. Obviously, the driver might also reject the later state changes, so hostapd still has to deal with errors at all steps along the way. That might be some added complexity, but I think it's still going to be worth it. 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
