No automatic reconnection after AP was down

[Bojan Prtvar]

On 17/09/2014 10:24, Bojan Prtvar wrote:
> Hi,
> 
> On 16/09/2014 20:56, Dan Williams wrote:
>>  wlan0:    skip - no WPA/RSN proto match
>>  wlan0: No suitable network found
>> The AP that's been selected is not broadcasting any WPA or RSN
>> information elements, so that AP is not WPA/RSN capable.  But since your
>> configuration requires WPA or RSN, there is a mismatch and you cannot
>> connect to the AP.
>>
>> This is probably an AP bug: it should not broadcasting beacons with the
>> wrong information, before it has completely set itself up.  Here, it
>> seems to be starting up and sending out a beacon without any encryption
>> indication, and then later (well, a second or two or three) it probably
>> changes the information elements to specify WPA or RSN.  If this AP is
>> actually a hotspot that you've created yourself, then the driver/hostap
>> should be fixed.
>>
>> wpa_supplicant does have some code to handle this, so if the AP does
>> change it's beacon I would expect the supplicant to notice and
>> eventually connect.  What does "iw wlan0 scan dump" show on your machine
>> for marvell_5GHz when this problem happens?
>>
> Thanks for shedding some light. When the problem happens "iw wlan0 scan
> dump" shows no output, when the box reconnects it gives nice&long report.
> Could you please point me to the piece of code which handles situation
> "when AP change it's bacon"? My wpa_supplicant is little dated, maybe I
> only need to back port existing fix. Or there may be an open space for
> further improvement.
> 
> Regards,
> Bojan

I need to revisit this topic, but this time I did my homework. It turns
out that Dan Williams was right and the AP initially does broadcast the
beacons with wrong information.

SIDE NOTE BEGIN:
Why we don't have some handy parser of IEs in dump_scan_res(), we only
do a hexdump?
SIDE NOTE END

The wpa_supplicant detects this situation, and bottom-line of handling
is in wpas_select_network_from_last_scan().
It does:

            if (wpa_supplicant_req_sched_scan(wpa_s))
                wpa_supplicant_req_new_scan(wpa_s, timeout_sec,
                                timeout_usec);

The problem is, I hit this condition in wpa_supplicant_req_sched_scan():

    if (wpa_s->sched_scanning) {
        wpa_dbg(wpa_s, MSG_DEBUG, "Already sched scanning");
        return 0;
    }

The wpa_supplicant_req_new_scan() never gets called and I don't get scan
results any more after this happens. So this looks like a race condition
over wpa_s->sched_scanning variable.

Idea for a workaround is simple(it works for me, but I would like to get
a feedback).

Regards,
Bojan

diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
index 1a0bc41..0956d82 100644
--- a/wpa_supplicant/events.c
+++ b/wpa_supplicant/events.c
@@ -1473,9 +1473,8 @@ static int
wpas_select_network_from_last_scan(struct wpa_supplicant *wpa_s,
                                return 0;
                        }
 #endif /* CONFIG_WPS */
-                       if (wpa_supplicant_req_sched_scan(wpa_s))
-                               wpa_supplicant_req_new_scan(wpa_s,
timeout_sec,
-                                                           timeout_usec);
+                       wpa_supplicant_req_new_scan(wpa_s, timeout_sec,
+                                                   timeout_usec);
                }
        }
        return 0;