Postpone scan for 500 ms if in the middle of association

Submitted by Dmitry Shmidt on Nov. 12, 2013, 8:49 p.m.

Details

Message ID 20131112205026.03BFC13FECA@ushik.mtv.corp.google.com
State Changes Requested
Headers show

Commit Message

Dmitry Shmidt Nov. 12, 2013, 8:49 p.m.
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
---
 wpa_supplicant/events.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Jouni Malinen Nov. 24, 2013, 10:09 a.m.
On Tue, Nov 12, 2013 at 12:49:24PM -0800, Dmitry Shmidt wrote:
> diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
> @@ -2122,7 +2122,7 @@ static void wpa_supplicant_event_disassoc_finish(struct wpa_supplicant *wpa_s,
>  			fast_reconnect_ssid = wpa_s->current_ssid;
>  #endif /* CONFIG_NO_SCAN_PROCESSING */
>  		} else if (wpa_s->wpa_state >= WPA_ASSOCIATING)
> -			wpa_supplicant_req_scan(wpa_s, 0, 100000);
> +			wpa_supplicant_req_scan(wpa_s, 0, 500000);
>  		else
>  			wpa_dbg(wpa_s, MSG_DEBUG, "Do not request new "
>  				"immediate scan");

How could this be in the "middle of association"? This is in
disassociation event handler, so obviously there is not supposed to be
an ongoing association at the time. Or is the driver doing something
strange like starting a new association automatically? If so, that
driver needs to be fixed or if that behavior needs to be supported, a
net driver capability advertisement is needed to be added to indicate
such behavior. Just delaying a scan request here by 400 ms does not make
any sense to me and is just making all other cases take more time at the
cost of whatever specific design this was trying to work around.
Dmitry Shmidt Nov. 24, 2013, 7:34 p.m.
On Sun, Nov 24, 2013 at 2:09 AM, Jouni Malinen <j@w1.fi> wrote:
> On Tue, Nov 12, 2013 at 12:49:24PM -0800, Dmitry Shmidt wrote:
>> diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
>> @@ -2122,7 +2122,7 @@ static void wpa_supplicant_event_disassoc_finish(struct wpa_supplicant *wpa_s,
>>                       fast_reconnect_ssid = wpa_s->current_ssid;
>>  #endif /* CONFIG_NO_SCAN_PROCESSING */
>>               } else if (wpa_s->wpa_state >= WPA_ASSOCIATING)
>> -                     wpa_supplicant_req_scan(wpa_s, 0, 100000);
>> +                     wpa_supplicant_req_scan(wpa_s, 0, 500000);
>>               else
>>                       wpa_dbg(wpa_s, MSG_DEBUG, "Do not request new "
>>                               "immediate scan");
>
> How could this be in the "middle of association"? This is in
> disassociation event handler, so obviously there is not supposed to be
> an ongoing association at the time. Or is the driver doing something
> strange like starting a new association automatically? If so, that
> driver needs to be fixed or if that behavior needs to be supported, a
> net driver capability advertisement is needed to be added to indicate
> such behavior. Just delaying a scan request here by 400 ms does not make
> any sense to me and is just making all other cases take more time at the
> cost of whatever specific design this was trying to work around.

You are right, thanks.

>
> --
> Jouni Malinen                                            PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP@lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap

Patch hide | download patch | download mbox

diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
index 4493772..2754276 100644
--- a/wpa_supplicant/events.c
+++ b/wpa_supplicant/events.c
@@ -2122,7 +2122,7 @@  static void wpa_supplicant_event_disassoc_finish(struct wpa_supplicant *wpa_s,
 			fast_reconnect_ssid = wpa_s->current_ssid;
 #endif /* CONFIG_NO_SCAN_PROCESSING */
 		} else if (wpa_s->wpa_state >= WPA_ASSOCIATING)
-			wpa_supplicant_req_scan(wpa_s, 0, 100000);
+			wpa_supplicant_req_scan(wpa_s, 0, 500000);
 		else
 			wpa_dbg(wpa_s, MSG_DEBUG, "Do not request new "
 				"immediate scan");