On Mon, 2011-01-31 at 13:47 +0200, Jouni Malinen wrote: > On Mon, Jan 31, 2011 at 05:08:35PM +0530, Rajkumar Manoharan wrote: > > On Mon, Jan 31, 2011 at 04:57:41PM +0530, Johannes Berg wrote: > > > Is that a big problem? We actually had this intentionally, and we go to > > > PS before going to sleep, so if the sleep is very short then we will not > > > be disconnected. Also, it's much easier this way to implement WoWLAN. > > I looked it as a problem ;) And if we use NM/supplicant, obviously the STA > > got disconnected. So just to align with that I sent the RFC. > > While this may behave differently if NM is running (wpa_supplicant > should not be being the disconnection on suspend), the comment about > Wake-on-WLAN is something that should be considered here. I would expect > there to be some interest in being able to support it and forcing a > disconnection on suspend would make that impossible. In addition, > extended PS mode from 802.11v will make it even more desirable to be > able to sleep for extended periods of time without dropping the > association for some use cases. If we force a disconnection here, we > would need to have a flag for disabling that if there is any chance of > the association being of use for something else after the resume or if > Wake-on-WLAN is enabled. I just don't see why we need the additional complexity of disabling it and then re-enabling it conditionally when we want WoWL or 11v extended PS? IOW, I'd rather leave it as is. It seems there isn't really a problem, but rather a perceived inconsistency that is being "fixed"? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
