[PATCH 1/1] Avoid double invocation of wpa_driver_nl80211_sta_remove function from ap_sta_disconnect context.

[Jithu Jance]

On Sun, Sep 18, 2016 at 12:34 AM, Jouni Malinen <j at w1.fi> 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