On Mon, Jul 04, 2016 at 11:50:18AM +0530, Jithu Jance wrote: > On Fri, Jul 1, 2016 at 11:39 PM, Jouni Malinen <j@xxxxx> 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? If I understood this description correctly, the patch I sent in the previous email should take care of this 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. So this is an issue with it taking more time in local processing to handle Deauthentication frame reception than it takes for the other side to send the Authentication frame after the Deauthentication frame(?). I'm not sure I understood how to "clear the cfg80211 state" part, though.. wpa_supplicant could obviously internally clear whatever state is needed without involving cfg80211, but to clear cfg80211 state, an nl80211 command needs to be issued.. sta_remove() maps to NL80211_CMD_DEL_STATION. Does the case of processing a received Deauthentication frame on AP/GO side somehow result in that nl80211 command sending out yet another Deauthentication frame from the AP? Or is it that this command reaching the WLAN driver (and from there firwmare) on its own is enough to cause the issue in this race condition case where the firmware has already received Authentication frame for a new connection? -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
