| Message ID | 20131112205026.03BFC13FECA@ushik.mtv.corp.google.com |
|---|---|
| State | Changes Requested |
| Headers | show |
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.
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
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");
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com> --- wpa_supplicant/events.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)