On 7 July 2015 at 17:00, Jouni Malinen <j@xxxxx> wrote: > 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.. At least one ath10k qca61x4 firmware seems to send Deauth when it gets a NullFunc from DA which doesn't have an internal peer entry. It doesn't seem to care whether peer is authenticated or associated though. Probably having none->auth, auth->assoc state transitions (instead of a single none->assoc) would be enough - at least for ath10k today. > 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. This seems pretty racy inherently. Driver/firmware actually needs to be aware of this requirement and make sure to avoid reordering Tx ACK processing and Rx. Since Tx/Rx engines are often (if not always?) independent of each other I imagine this could be a common problem across many devices today but perhaps not easily observable due to narrow time window this could happen in. Anyway - thank you for your great insight! Michał -- 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
