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