On Mon, Sep 05, 2016 at 05:33:07PM +0300, andrei.otcheretianski@xxxxxxxxx wrote: > In some cases, after a sudden AP disappearing and reconnection to > another AP in the same ESS, if another scan ocures, wpa_supplicant might > try to roam to the old AP (if it was better ranked than the new one) > because it is still saved in BSS list and the blacklist entry was > cleared in previous reconnect. This attempt is going to fail because > the AP is not present anymore and it'll cause long disconnections. > > Remove an AP that is probably out of range from BSS list to avoid > such disconnections. What is that "probably out of range" expectation based on? > @@ -2617,6 +2626,9 @@ static void wpa_supplicant_event_disassoc_finish(struct wpa_supplicant *wpa_s, > last_ssid = wpa_s->current_ssid; > wpa_supplicant_mark_disassoc(wpa_s); > > + if (curr) > + wpa_bss_remove(wpa_s, curr, "Connection to AP lost"); This gets called when the AP is sending out a Deauthentication/Disassociation frame. If we receive that frame, obviously the AP is not out of range.. I don't see why we would remove a BSS entry for an AP from which we are able to receive a frame. Maybe the AP selection after the scan should better take into account the relative times of when the BSS entries have been last updated if an old scan result is causing problems for roaming. For the case where we can clearly identify that the driver is indicating that the AP is not reachable anymore (e.g., missing beacons, etc.), it might be more reasonable to remove the cached BSS entry from wpa_supplicant before the entry expires due to scans not being able to update it. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
