On 9/18/24 09:53, Benjamin Berg wrote:
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?
I'm sorry, but I'm too busy with other things right now to do a good job of thinking
through your proposal. If we _must_ (re)connect for some reason, we should take the 'best'
AP, but if we are already associated, there should be some friction to roaming. As long
a you are satisfied you are considering and meeting these goals, then probably you
are fine.
Thanks,
Ben
Benjamin
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
