WPS Failure due to explicit deauth

[Jithu Jance]

On Fri, Jul 1, 2016 at 11:39 PM, Jouni Malinen <j at w1.fi> wrote:
> Does the GO/AP send a Disassociation or Deauthentication frame for the
> first association after the Authentication frame for the second
> association has been sent? Or is this simply an internal issue within
> the GO/AP in a sense that it does not handle a sequence where
> STA-initiated disassociation/deauthentication is followed by a new
> authentication/association attempt very quickly? In either case, the
> real issues seems to be on the GO/AP side and this should be considered
> only from the view point of interoperability workaround with a deployed
> device as far as STA-side functionality is concerned.
>
Yes. I was talking from AP/GO fix perspective as the STA/GC devices
are running windows. We are seeing both scenarios that you have
mentioned.
The AP/GO is a dongle MAC device (device_ap_sme is set) which handles
assoc frames in fw itself.

First case:    During the port de-authorize context
(setPortUnauthorized API context), the AP/GO driver/fw sends a deauth
to the STA/GC and these clients move to assoc state.
But the explicit deauth from supplicant which happens after 10ms after
port de-authorization, terminates the second association.

For this case, your suggestion of changing the supplicant's explicit
deauth code for AP/GO to do it based
on a timeout context(which gets fired only when client doesn't issue a
deauth/disconnect or locally generated
deauth event has come) should work. Is it fine to do that for the
above scenario?

Second case:  The client sends deauth req before AP/GO does. This is
immediately followed
by Auth (with in 7ms or so). The deauth ind received on GO side is
given up to the supplicant which calls the sta_remove function.
But by the time it reaches firmware, the auth frame for second assoc
has come. This sta_remove API context
terminates the connection and client never connects back. Is there a
way that we can send the deauth up and just
clear the cfg80211 & supplicant states without resulting in the
invocation of sta_remove function. This check can be based on
"device_ap_sme"
check where the dongle can respond with a deauth to the STA/GC to
bridge this time gap. Kindly share your thoughts.


Thanks,

-- 

Jithu Jance