Re: Association race when acting as AP?

[Jouni Malinen <j@w1.fi>]

On Thu, Jul 02, 2015 at 10:24:33AM +0200, Michal Kazior wrote:
> After looking into hostapd code I noticed something strange and I wonder if
> anyone else is already aware of this problem:
> 
>  1. AP starts
>  2. STA->AP auth OTA
>  3. AP->STA auth OTA
>  4. STA->AP assoc req OTA
>  5. AP->STA assoc resp OTA
>  6. STA sends NullFunc with "STA will go to sleep" bit set
>  7. AP driver/device sees a frame from with unknown TA/SA and issues Deauth
> w/ Reason 7
>    (this Deauth doesn't originate from hostapd; it comes from the device FW
> in my case)

If there is a driver or firmware design that sends these
Deauthentication frames on their own, they better be able to handle race
conditions and enable this functionality at the correct time.. Sure,
cfg80211 and hostapd may need modifications to make this work better,
but this needs to be done for things to work properly. There's a good
reason for hostapd having code to check the internal STA associated
flag before triggering deauthentication based on EVENT_RX_FROM_UNKNOWN
events..

> 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:

Adding a STA entry before sending Association Response frame would be
fine, but this change would do more: it would claim that STA entry to be
in associated state. That is not correct from the IEEE 802.11 standard
view point. On the AP side, a STA becomes associated when an ACK frame
to the (Re)Association Response frame is received by the AP.

-- 
Jouni Malinen                                            PGP id EFC895FA