Re: Association race when acting as AP?

Re: Association race when acting as AP?

[Johannes Berg]

[please try to send w/o html if you're CC'ing the linux-wireless list]

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

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

johannes

Re: Association race when acting as AP?

[Michal Kazior]

On 2 July 2015 at 10:38, Johannes Berg <johannes@sipsolutions.net> 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.


Michał

Re: Association race when acting as AP?

[Michal Kazior]

On 2 July 2015 at 10:43, Eliad Peller <eliad@wizery.com> wrote:
> On Thu, Jul 2, 2015 at 11:38 AM, Johannes Berg <johannes@sipsolutions.net>
> wrote:
>>
>> [please try to send w/o html if you're CC'ing the linux-wireless list]
>>
>> > 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.
>>
> there was some implementation error. it was fixed later on.
>
> also, take a look at this thread:
> http://thread.gmane.org/gmane.linux.kernel.wireless.general/88421

Thanks! Looks like you guys hit this with EAPOL frames. I'll look into it more.

Is there any particular reason why these TI-OpenLink patches weren't
submitted/merged to hostap?


Michał

Re: Association race when acting as AP?

[Johannes Berg]

On Thu, 2015-07-02 at 12:28 +0200, Michal Kazior wrote:

> > 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?). 

We'd send a deauth with "class 3 frame from unassociated STA" reason :)

> I.e. station should be transitioned to Assoc state
> before sending the Assoc Resp frame.

Yeah, I guess that's still true, but it doesn't preclude adding the
station before auth response and sending an auth response depending on
whether it could be added; perhaps we need to set it to authenticated
just before sending the frame as well though.


johannes

Re: Association race when acting as AP?

[Eliad Peller]

On Thu, Jul 2, 2015 at 1:39 PM, Michal Kazior <michal.kazior@tieto.com> wrote:
> On 2 July 2015 at 10:43, Eliad Peller <eliad@wizery.com> wrote:
>> On Thu, Jul 2, 2015 at 11:38 AM, Johannes Berg <johannes@sipsolutions.net>
>> wrote:
>>>
>>> [please try to send w/o html if you're CC'ing the linux-wireless list]
>>>
>>> > 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.
>>>
>> there was some implementation error. it was fixed later on.
>>
>> also, take a look at this thread:
>> http://thread.gmane.org/gmane.linux.kernel.wireless.general/88421
>
> Thanks! Looks like you guys hit this with EAPOL frames. I'll look into it more.
>
> Is there any particular reason why these TI-OpenLink patches weren't
> submitted/merged to hostap?
>
nothing particular, AFAIR.
they needed further review/cleanup before upstream, and we just didn't
get to it.

Eliad.

Re: Association race when acting as AP?

[Jouni Malinen]

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

Re: Association race when acting as AP?

[Michal Kazior]

On 7 July 2015 at 17:00, Jouni Malinen <j@w1.fi> 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ł