RE: [PATCH 14/18] wpa_supplicant: remove disconnected APs from BSS table

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Jouni Malinen [mailto:j@xxxxx]
> Sent: Tuesday, September 27, 2016 00:22
> To: Otcheretianski, Andrei <andrei.otcheretianski@xxxxxxxxx>
> Cc: hostap@xxxxxxxxxxxxxxxxxxx; Spinadel, David <david.spinadel@xxxxxxxxx>
> Subject: Re: [PATCH 14/18] wpa_supplicant: remove disconnected APs from
> BSS table
> 
> 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?

Because the event is locally generated and the reason is DISASSOC_DUE_TO_INACTIVITY

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

It is also called for locally generated DEAUTH, otherwise curr==NULL.

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

Prioritizing by timestamp may break other roaming considerations.. 

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

This is exactly what we do. Please note that there is also mac80211's patch that clears the bss cache entry ("mac80211: remove disconnected APs from BSS table").

> 
> --
> Jouni Malinen                                            PGP id EFC895FA

_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux