On Wed, 2024-09-18 at 09:17 -0700, Ben Greear wrote:
> On 9/18/24 09:12, Berg, Benjamin wrote:
> > On Wed, 2024-09-18 at 07:08 -0700, Ben Greear wrote:
> > > On 9/18/24 05:39, Benjamin Berg wrote:
> > >
> > > [SNIP]
> > > Or is that somehow handled in the current code elsewhere?
> >
> > No, I believe it does not do anything since the commit I mentioned.
> >
> > If bss_in_list is set and it is better, then it will have already been
> > sorted to the start by find_better_target.
> >
> > If bss_in_list is not set, then obviously the code will not be reached
> > and the found target is used.
> >
> > And yes, that does mean that we are effectively ignoring the
> > order/precedence value in the neighbor report (apart from a zero
> > preference to mean "disallowed"). But, I do not think it is a change in
> > behaviour at this point in time.
>
> We need to dampen roams in the case where a user sits between two APs at nearly the same
> RSSI (well, same estimated tput). It should not roam back and forth every time a small environmental change
> happens. The code you are removing at least attempted to do that as far as I
> can tell.
Hmm, right, I misunderstood. Yes, it prevents the roam if estimated
throughput is not better by a margin.
So, we have this code path (slightly updated by this patch) in
wnm_scan_process:
if (pre_scan_check) {
struct os_reltime age;
if (!bss)
return 0;
os_reltime_age(&bss->last_update, &age);
if (age.sec >= 10)
return 0;
#ifndef CONFIG_NO_ROAMING
if (current_bss && bss != current_bss &&
wpa_supplicant_need_to_roam_within_ess(wpa_s, current_bss,
bss))
return 0;
#endif /* CONFIG_NO_ROAMING */
}
We could do something similar if we are allowed to stay on current_bss.
Basically we could just call wpa_supplicant_need_to_roam_within_ess
outside of the "pre_scan_check" if we are allowed to stay with the
current BSS. If that code decides that we should not roam, we simply
select current_bss as our target and are done.
Does that seem reasonable to you? We could even just have the same
100/16 logic there … but, is that actually better?
Benjamin
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
