WPS Failure due to explicit deauth

[Jouni Malinen]

On Fri, Jul 01, 2016 at 10:55:21AM +0530, Jithu Jance wrote:
> Request help with a wps-failure issue. The explicit deauth code in the
> function: ieee802_1x_finished is causing some interop issues. This
> issue happens when the peer device (GC/STA) is very aggressive in
> sending in the auth request following the EAP-FAIL. In one such
> scenario, the auth request from peer has reached GO/AP in around
> 7-10ms. So in this case this explicit deauth reaches firmware after
> driver/fw has moved to auth/assoc state and terminates the on-going
> connection.

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.

> Would it be okay to make this explicit deauth code conditional under a
> supplicant conf variable?

I don't think that that would be a good idea. The STA-initiated
disassociation was needed to work around issues with some AP WPS
implementations. Making this behavior configurable would mean that
whoever disables this will get those earlier issues back..

I'd much rather consider changes where ieee802_1x_finished() would not
issue the Deauthentication request immediately in case WPS was used
(i.e., do not change behavior for other EAP cases) and instead, wait a
short time for the AP to initiate deauthentication. If that does not
show up within N ms, the station should still have an automatic trigger
for doing the disconnection.

-- 
Jouni Malinen                                            PGP id EFC895FA