[PATCH] Do not retry scan after failure if operating in ap_mode

Jouni Malinen j at w1.fi
Sat Aug 8 16:17:47 EDT 2015


On Wed, Aug 05, 2015 at 01:42:35AM +0300, pasi.sjoholm at jolla.com wrote:
> Commit 2d9c99e37b29a639dafa431df38e1586a31ba887 introduced
> a regression while running in ap_mode together with ap_scan
> configured with value of 2.
> 
> Retrying caused following path to be called:
> wpa_supplicant_req_scan()->wpa_supplicant_scan()->
> wpa_supplicant_assoc_try()->wpa_supplicant_associate()->
> wpa_supplicant_create_ap()
> 
> Which eventually teared down the currently configured
> ap_mode by calling wpa_supplicant_ap_deinit().

Would you be able to provide a debug log showing the sequence in which
this is hit?

> @@ -186,6 +186,9 @@ static void wpas_trigger_scan_cb(struct wpa_radio_work *work, int deinit)
>  		if (wpa_s->disconnected)
>  			retry = 0;
>  
> +		if (wpa_s->last_ssid && wpa_s->last_ssid->mode == WPAS_MODE_AP)
> +			retry = 0;

This would imply that we are currently running an AP mode interface and
something start a scan. What was that something? And what happened next?
I'm trying to understand especially that wpa_supplicant_assoc_try() call
in the sequence. Why would that be called here when AP mode was already
running?

-- 
Jouni Malinen                                            PGP id EFC895FA


More information about the HostAP mailing list