No automatic reconnection after AP was down

Bojan Prtvar bojan.prtvar
Wed Sep 24 04:12:30 PDT 2014

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.

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

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,

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


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_usec);
+                       wpa_supplicant_req_new_scan(wpa_s, timeout_sec,
+                                                   timeout_usec);
        return 0;

More information about the Hostap mailing list