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
On 7 July 2015 at 17:00, Jouni Malinen <[email protected]> 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ł