On Fri, 2013-05-10 at 08:39 -0600, Daniel Drake wrote: > On Thu, May 9, 2013 at 5:19 PM, Dan Williams <[email protected]> wrote: > > So the code in link_timeout_cb() only gets run when the wifi device is > > already connected and then somehow gets disconnected. Were you hitting > > this issue while connected to the AP, getting disconnected, and then the > > AP rejected the reconnect? > > You are frighteningly familiar with this code. That is exactly what happens. > > > This patch will break the AP-out-of-range or AP-turned-off cases; so > > instead of your patch, does this one fix your issue? We're already > > tracking whether or not the supplicant can talk to the AP, and the AP > > shouldn't be rejecting you during the AUTH phase, just the ASSOC phase. > > So with this patch, if when the supplicant reconnects it's able to get > > to the ASSOC phase, the AP shouldn't get removed from the list on link > > timeout. > > I had assumed that the AP-out-of-range and similar cases would be > handled with a signal from the supplicant saying "BSS removed". > Anyway, your patch works.
The supplicant has a BSS timeout too, and APs don't get removed from the supplicant's list until the next scan after the timeout happens. So it could be long after you're out of range, and that means NM would keep trying to reconnect to the AP that's not there because it doesn't know it's gone. There's no good way to know that an AP isn't in range anymore besides probe-scanning for it after you lose the connection to it, which would be a good thing to do. But would also require some supplicant enhancements. Dan _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
