Re: [PATCH] wifi: don't remove AP upon link lost event
On Fri, 2013-05-10 at 16:18 -0600, Daniel Drake wrote: > On Fri, May 10, 2013 at 12:14 PM, Dan Williams wrote: > > 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. > > OK, the approach in your patch makes sense. I've been running it all > day, the AP has kicked me off several times and each time NM recovers > nicely. Hah, excellent :) Thanks for testing! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] wifi: don't remove AP upon link lost event
On Fri, May 10, 2013 at 12:14 PM, Dan Williams wrote: > 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. OK, the approach in your patch makes sense. I've been running it all day, the AP has kicked me off several times and each time NM recovers nicely. Thanks Daniel ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] wifi: don't remove AP upon link lost event
On Fri, 2013-05-10 at 08:39 -0600, Daniel Drake wrote: > On Thu, May 9, 2013 at 5:19 PM, Dan Williams 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 networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] wifi: don't remove AP upon link lost event
On Thu, May 9, 2013 at 5:19 PM, Dan Williams 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. Thanks Daniel ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
