On Thu, Jan 02, 2020 at 07:41:42AM -0800, Ben Greear wrote: > On 01/02/2020 12:38 AM, Jouni Malinen wrote: > > I don't want to expose this type of very specific parameters in > > configuration file since this can result in expectation of those values > > being maintained in the future and that resulting in additional > > constraints on the implementation. If something needs to be > > configurable, I'd prefer to consider some higher level value to indicate > > how aggressive roaming should be and then automatically convert from > > that to internal parameters for the algorithm so that the design can be > > changed without having to touch the definition of the configuration > > parameter. > > I'm guessing the vast majority of users never touch the config file > themselves...it is auto-generated by something at a higher level. Maybe > let the higher level thing deal with the simplified setting value > and let it tune the more specific values in supplicant? I'd consider that "higher level thing" the same as "users", i.e., it is whatever is generating the configuration for wpa_supplicant. I don't want to expose configuration parameters for low level details if those details may change completely based on how the internal wpa_supplicant implementation is changed. > > > diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c > > > @@ -1778,8 +1784,17 @@ static int wpa_supplicant_need_to_roam(struct wpa_supplicant *wpa_s, > > > min_diff = 3; > > > else if (current_bss->level < -70) > > > min_diff = 4; > > > - else > > > + else if (current_bss->level < -60) > > > min_diff = 5; > > > + else if (current_bss->level < -50) > > > + min_diff = 8; > > > + else if (current_bss->level < -40) > > > + min_diff = 10; > > > + else if (current_bss->level < -30) > > > + min_diff = 20; > > > + else > > > + min_diff = 30; > > > > I'm not sure this is really needed. There is now a cur_snr > GREAT_SNR > > check that will in practice skip roaming in cases where the signal level > > from the current BSS is sufficiently good. > > Based on my current understanding of things, I'd change the logic above > to keep the min_diff larger even at very weak signals since roaming is so > disruptive to user experience, and RSSI is likely to > fluctuate more than a few db. This is proposing changes for cur_level >= -60. GREAT_SNR = 25 which would mean that these min_diff = 8, 10, 20, or 30 cases would not really have any impact to the current behavior since GREAT_SNR overrides (skip roam) anyway. > Does the current code keep the station from roaming back and forth when there > are two APs at about -70? Roaming back and forth should be significantly reduced. Roaming to the one of these APs that have "significantly better" throughput estimate should happen in one direction. Signal level based allowance for roaming would depend on the noise floor since -70 would be pretty close to GREAT_SNR, but not necessarily above it in environment where noise floor is high. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
