On Fri, 2016-10-21 at 09:20 -0500, Denis Kenzior wrote: > > It's actually not clear to me that this is really how it should be. > > There's a point to be made that taking a more holistic "link > > quality" would be a better choice. That's related, but maybe can be > > a separate discussion. > Can you elaborate on this 'link quality' idea? Well, I didn't really want to - getting 3 system folks into a room will result in 4 different ways of doing it - but you can take into account not just the RSSI, but also the bitrate you can reasonably use on the channel/with the AP, the noise you can perhaps detect (if you can), the amount of packet loss or retransmissions you experience, etc. I think that some systems (Android, maybe Windows) already do something more complex than pure RSSI indicators, but I don't really know for sure. > > Yes, this would be ideal. > > > > [...] see my other email > This sounds really brittle. Furthermore, we also need a facility to > know when signal strength is getting low to trigger roaming > logic. This would mean sharing CQM facility between roaming & signal > strength notifications. As you wrote above, things become quite > impractical. This would likely go through the supplicant anyway, so it could manage proper range overlaps etc. for this. It does seem brittle if we just have a single value, but if we add low/high thresholds (with hysteresis) then I think we can do this, and gain more flexibility in the process. But let's discuss more details over in the other email I just sent :) johannes