Patchwork Postpone scan for 500 ms if in the middle of association

login
register
mail settings
Submitter Dmitry Shmidt
Date Nov. 12, 2013, 8:49 p.m.
Message ID <20131112205026.03BFC13FECA@ushik.mtv.corp.google.com>
Download mbox | patch
Permalink /patch/290775/
State Changes Requested
Headers show

Comments

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(-)
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

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");