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

[Jithu Jance]

>>  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.
Didn't get a chance to further test this. If i come across similar
issue, i will update you.

> This missed the needed changes in wpa_supplicant/ctrl_iface.c
Looks like i missed the build before patch generation. Really sorry about
this and
 thanks for being kind enough to fix it.




- Jithu Jance* *


On Sat, Feb 25, 2012 at 8:57 PM, Jouni Malinen <j at w1.fi> wrote:

> 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
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20120229/28d1857d/attachment.htm