[PATCH] Fix scan retry after a failure
kalle.valo at canonical.com
Mon Oct 11 02:44:36 EDT 2010
Jouni Malinen <j at w1.fi> writes:
> On Wed, Oct 06, 2010 at 03:46:46PM +0300, Kalle Valo wrote:
>> With broadcom's "wl" driver the first scan always fails. (Apparently it also
>> doesn't send scan results ready signals, but let's forget it for now.) With
>> connman's five minute scan interval it meant that it would take five minutes
>> from boot until a wireless connection was established.
>> The reason is that currently wpasupplicant doesn't handle scan retries
>> and it goes directly to INACTIVE state:
>> 14:23:09 wpa_supplicant: Scan timeout - try to get results
>> 14:23:09 wpa_supplicant: Failed to get scan results
>> 14:23:09 wpa_supplicant: Failed to get scan results - try scanning again
>> 14:23:09 wpa_supplicant: State: SCANNING -> INACTIVE
>> Instead of going to INACTIVE set wpa_s->scan_req to make it explicit
>> that this is a requested scan and fix check in wpa_supplicant_req_new_scan().
> I would be fine with this for the case where the initial scan is
> failing. However, I'm not sure I would really like to see this hitting
> for other possible error cases, i.e., I don't want this to have a
> possibility of hitting a look where a new scan is requested one second
> after failure to get scan results regardless of the current state..
Makes sense. I'll try to come up with something and send v2.
>> @@ -893,6 +894,7 @@ static void wpa_supplicant_event_scan_results(struct wpa_supplicant *wpa_s,
>> wpa_printf(MSG_DEBUG, "Failed to get scan results - try "
>> "scanning again");
>> + wpa_s->scan_req = 2;
>> wpa_supplicant_req_new_scan(wpa_s, 1, 0);
> This, I would hope to be done only if the failure happened on the
> initial scan attempt and in that case, wpa_s->scan_req = 1 may be better
> option here since that matches with the value used in the initial scan.
Ok, I'll change it.
Thanks for the review.
More information about the HostAP