On Sun, Sep 18, 2016 at 12:34 AM, Jouni Malinen <j@xxxxx> wrote: > > This is the former case and if this is made conditional, all drivers > that do not set WPA_DRIVER_FLAGS_DEAUTH_TX_STATUS would lose the reason > code when they get only the second call from ap_sta_remove(). I don't > think this is acceptable. > > In addition, the sta == NULL case would return from ap_sta_disconnect() > without even registering the ap_sta_disassoc_cb_timeout() callback at > all. That does not sound correct either, i.e., this condition on > skipping the hostapd_drv_sta_deauth() call should likely apply only if > sta != NULL. > > For the reason code disappearing issue, one could consider extending > hostapd_drv_sta_remove() support passing a reason code to the driver, > but I'm not really sure this is the correct thing to do.. In other > words, I think I'd rather leave this as-is. Thanks Jouni for detailed explanation. >Other than debug logs showing some warnings, are there any real issues noticeable by external devices that this patch is fixing? Yes. For STA devices supporting firmware roam, the first deauth clears the assoc and kicks the firmware to scan and search for similar profile networks. Now the second deauth from AP/GO pre-empts the join process. For e.g In P2P case, the deauth following WPS EAP-FAIL will cause the P2P GC to disassociate. Now for cases, where GC tries to connect back immediately, the P2P GO would have moved to authenticated state internally and the second deauth from supplicant pre-empts this join process. Do you see any other solution to avoid this second deauth? - Jithu Jance _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
