[PATCH] Force disconnect a P2P Client/STA from GO/AP side

[Jouni Malinen]

On Tue, Dec 20, 2011 at 04:15:41AM -0800, Jithu Jance wrote:
> The command that I added is slightly different in functionality. New command will send disassociate req and
> then remove sta_info abruptly without waiting to remove sta_info on ap_handle_timer. Few days back while testing
> I saw that STA/P2P client state is showing inconsistent assoc status with normal disassociate cmd. This
> is mostly seen when P2P Client/STA connects back before or during the ap_handle_timer INACTIVITY timeout. In this
> scenario, AP shows the STA as disconnected, but the STA shows as associated. Seems like in those cases, the deauth
> Frame was not been received by STA. With latest hostap code, I am unable to see this issue. Of course, it disconnects two times
> on issuing disassociate (One on sending the disassoc frame and then on the inactivity timeout [sending deauth frame]).
> Both AP and STA states are consistent. I will get back to you, if I could reproduce this inconsistent behavior and find the root cause.

If this issue shows up with the existing deauthenticate/disassociate
commands in hostapd, those commands need to be fixed. This area should
be identical between hostapd and wpa_supplicant AP mode operations.

> Yes, these commands need to be available for wpa_cli as well. Attaching the patch for the same below. Please see whether
> the patch is okay.
> 
> 
> [PATCH] Move disassociate, deauthenticate commands to ctrl_iface_ap.c so that
>  it is accessible for wpa_cli(with CONFIG_AP option enabled).

This missed the needed changes in wpa_supplicant/ctrl_iface.c for the
new commands and broke hostapd build. I fixed those and applied a
cleaned up version of the patch.

-- 
Jouni Malinen                                            PGP id EFC895FA