Association race when acting as AP?

Michal Kazior michal.kazior at
Thu Jul 2 06:28:38 EDT 2015

On 2 July 2015 at 10:38, Johannes Berg <johannes at> wrote:
> [please try to send w/o html if you're CC'ing the linux-wireless list]

Ah, sorry. I suspect the "plain text mode" in gmail/www got disabled
for some reason for that e-mail..

>> To me this looks like a race in hostapd. The station should be
>> installed to driver _before_ sending Assoc Resp frame, not after. My
>> quick-n-dirty hack seems to help:
> [...]
>> Is anyone aware of this problem already? Anyone working on it? Any
>> gotchas I should be aware of before I go into fixing this in a proper
>> way? Or am I missing something and this isn't actually a problem?
> The TI folks had a similar patch that broke open networks, not sure
> what was wrong there.
> Ultimately, depending on the nl80211 capabilities, the station should
> in fact be added (as unauthenticated) before even sending the
> authentication response frame, and then stepping through the stages
> appropriately.

While I think it does make sense (I thought of this too, sounds
desirable) I think it wouldn't solve the race problem entirely. The
station might no longer be rejected with Deauth but may end up
confusing AP's internal/offloaded STA powersave state depending on
implementation detail (what do you do when you receive NullFunc from a
station that you don't know assoc id of or isn't fully initialized as
associated?). I.e. station should be transitioned to Assoc state
before sending the Assoc Resp frame.

> It should also react to errors by sending a negative association
> response I guess.

Good point.


More information about the HostAP mailing list