[PATCH v2 2/2] WNM: Use standard BSS selection and enable abridged bit handling

[Ben Greear]

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:
>>> From: Benjamin Berg <benjamin.berg at intel.com>
>>>
>>> Most of the logic to reject BSSs during transition has been moved
>>> into
>>> wnm_is_bss_excluded. In addition to this, since commit 67bf89f55442
>>> ("WNM: Choose the best available BSS, not just the first one") we
>>> will
>>> simply choose the BSS with the best throughput.
>>
>> It looks like you are dropping the logic that will keep it from
>> roaming
>> unless the change in estimated throughput is relatively large?
>>
>> [snip]
>>
>>> -	if ((!target->est_throughput && !bss_in_list-
>>>> est_throughput) ||
>>> -	    (target->est_throughput > bss_in_list-
>>>> est_throughpubelieve it does not do anything since the commit I
>>> mentionedt &&
>>> -	     target->est_throughput - bss_in_list->est_throughput
>>>>
>>> -	     bss_in_list->est_throughput >> 4)) {
>>> -		/* It is more than 100/16 percent better, so
>>> switch. */
>>> -		return target;
>>> -	}
>>
>> 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.

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com