<div>>> The command that I added is slightly different in functionality. New command will send disassociate req and<br>>> then remove sta_info abruptly without waiting to remove sta_info on ap_handle_timer. Few days back while testing<br>
>> I saw that STA/P2P client state is showing inconsistent assoc status with normal disassociate cmd. This<br>>> is mostly seen when P2P Client/STA connects back before or during the ap_handle_timer INACTIVITY timeout. In this<br>
>> scenario, AP shows the STA as disconnected, but the STA shows as associated. Seems like in those cases, the deauth<br>>> Frame was not been received by STA. With latest hostap code, I am unable to see this issue. Of course, it disconnects two times<br>
>> on issuing disassociate (One on sending the disassoc frame and then on the inactivity timeout [sending deauth frame]).<br>>> 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.<br>
</div><div>Didn't get a chance to further test this. If i come across similar </div><div>issue, i will update you.</div><div><br></div><div>> This missed the needed changes in wpa_supplicant/ctrl_iface.c</div><div>
Looks like i missed the build before patch generation. Really sorry about this and</div><div> thanks for being kind enough to fix it.</div><div><br></div><div><br></div><div><br></div><div><br></div><div>- Jithu Jance<b style="color:rgb(102,102,102)"> </b></div>
<div>
<br><br><div class="gmail_quote">On Sat, Feb 25, 2012 at 8:57 PM, Jouni Malinen <span dir="ltr"><<a href="mailto:j@w1.fi">j@w1.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Dec 20, 2011 at 04:15:41AM -0800, Jithu Jance wrote:<br>
> The command that I added is slightly different in functionality. New command will send disassociate req and<br>
> then remove sta_info abruptly without waiting to remove sta_info on ap_handle_timer. Few days back while testing<br>
> I saw that STA/P2P client state is showing inconsistent assoc status with normal disassociate cmd. This<br>
> is mostly seen when P2P Client/STA connects back before or during the ap_handle_timer INACTIVITY timeout. In this<br>
> scenario, AP shows the STA as disconnected, but the STA shows as associated. Seems like in those cases, the deauth<br>
> Frame was not been received by STA. With latest hostap code, I am unable to see this issue. Of course, it disconnects two times<br>
> on issuing disassociate (One on sending the disassoc frame and then on the inactivity timeout [sending deauth frame]).<br>
> 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.<br>
<br>
</div>If this issue shows up with the existing deauthenticate/disassociate<br>
commands in hostapd, those commands need to be fixed. This area should<br>
be identical between hostapd and wpa_supplicant AP mode operations.<br>
<div class="im"><br>
> Yes, these commands need to be available for wpa_cli as well. Attaching the patch for the same below. Please see whether<br>
> the patch is okay.<br>
><br>
><br>
> [PATCH] Move disassociate, deauthenticate commands to ctrl_iface_ap.c so that<br>
> it is accessible for wpa_cli(with CONFIG_AP option enabled).<br>
<br>
</div>This missed the needed changes in wpa_supplicant/ctrl_iface.c for the<br>
new commands and broke hostapd build. I fixed those and applied a<br>
cleaned up version of the patch.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Jouni Malinen PGP id EFC895FA<br>
_______________________________________________<br>
HostAP mailing list<br>
<a href="mailto:HostAP@lists.shmoo.com">HostAP@lists.shmoo.com</a><br>
<a href="http://lists.shmoo.com/mailman/listinfo/hostap" target="_blank">http://lists.shmoo.com/mailman/listinfo/hostap</a><br>
</div></div></blockquote></div><br></div>