[PW_SID:946859] Roam blacklisting and scan BSS groups #456
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is taken care of by the individual cache items and if none exist, tar fails.
Allowing the timeout blacklist to be disabled has introduced a bug where a failed connection will not result in the BSS list to be traversed. This causes IWD to retry the same BSS over and over which be either a) have some issue preventing a connection or b) may simply be unreachable/out of range. This is because IWD was inherently relying on the timeout blacklist to flag BSS's on failures. With it disabled there was nothing to tell network_bss_select that we should skip the BSS and it would return the same BSS indefinitely. To fix this some of the blacklisting logic was re-worked in station. Now, a BSS will always get network blacklisted upon a failure. This allows network.c to traverse to the next BSS upon failure. For auth/assoc failures we will then only timeout blacklist under certain conditions, i.e. the status code was not in the temporary list. Fixes: 77639d2 ("blacklist: allow configuration to disable the blacklist")
To both prepare for some new blacklisting behavior and allow for easier consolidation of the network-specific blacklist include a reason enum for each entry. This allows IWD to differentiate between multiple blacklist types. For now only the existing "permanent" type is being added which prevents connections to that BSS via autoconnect until it expires. By including a type into each entry we now have additional search criteria and can have multiple entires of the same BSS with different reasons. This was done versus a bitmask because each blacklist reason may have a different expiration time. We want to maintain individual expirations to have the best "memory" of past events rather than overwriting them. Future patches will lump in the temporary network blacklist as well as a new roaming blacklist type.
When pruning the list check_if_expired was comparing to the maximum amount of time a BSS can be blacklisted, not if the current time had exceeded the expirationt time. This results in blacklist entries hanging around longer than they should, which would result in them poentially being blacklisted even longer if there was another reason to blacklist in the future. Instead on prune check the actual expiration and remove the entry if its expired. Doing this removes the need to check any of the times in blacklist_contains_bss since prune will remove any expired entries correctly.
This is meant to replace the blacklist held in network objects, known as the temporary blacklist. For these entires there is no expiration as it will be up to network.c to remove them as it does now internally.
Remove the temporary blacklist from network.c and use the new BLACKLIST_REASON_TRANSIENT_ERROR reason.
This adds a new blacklist reason as well as an option to configure the timeout. This blacklist reason will be used in cases where a BSS has requested IWD roam elsewhere. At that time a new blacklist entry will be added which will be used along with some other criteria to determine if IWD should connect/roam to that BSS again.
This introduces a higher level grouping to BSS's to improve sorting
as opposed to purely rank based sorting. The reason for this is to
handle roam request-based blacklisting where we want to encourage
IWD to avoid BSS's that have requested we roam elsewhere, but also
not fully ban these BSS's (i.e. BLACKLIST_REASON_CONNECT_FAILED).
This new concept introduces 4 group types, in order of worse to
best:
- Blacklisted - the BSS has a permanent timeout blacklist
- Under threshold - the BSS is under the set RSSI threshold
- Above threshold - the BSS is above the set RSSI threshold
- Optimal - The BSS is not "roam blacklisted" and is above the
set RSSI threshold.
When sorting the BSS group will be considered before rank. This
means we will still prefer roam blacklisted BSS's above those that
are under the set RSSI threshold. BSS's within the same group are
still compared by their rank/signal.
The new group sorting logic was added via a macro
__scan_bss_rank_compare. This was done since station uses a separate
roam_bss structure to sort roam candidates which can also take
advantage of this new sorting. The macro is agnostic to the type as
long as the structure member names match.
If the BSS is requesting IWD roam elsewhere add this BSS to the blacklist using BLACKLIST_REASON_ROAM_REQUESTED. This will lower the chances of IWD roaming/connecting back to this BSS in the future. In addition we also needed to update the roam_bss sorting to use __scan_bss_rank_compare so we sort based on the new groupings rather than only rank/rssi.
If an AP directed roam frame comes in while IWD is roaming its still valuable to parse that frame and blacklist the BSS that sent it. This can happen most frequently during a roam scan while connected to an overloaded BSS that is requesting IWD roams elsewhere.
In station_roam_scan_notify BSS candidates were being ignored if their rank was not better than the current AP. This check needed to be changed to first check the BSS group, then the rank (only if the groups were equal). This takes into account the current BSS roam blacklisting status rather than only rank.
Owner
Author
|
Fetch PR Prep - Setup ELL Make Distcheck Build - Configure Make Check Make Check w/Valgrind Incremental Build with patches |
github-actions
bot
force-pushed
the
workflow
branch
2 times, most recently
from
6a6b0cc to
55901fd
Compare
github-actions
bot
force-pushed
the
workflow
branch
from
55901fd to
8713461
Compare
github-actions
bot
force-pushed
the
workflow
branch
3 times, most recently
from
a2c9985 to
624cea8
Compare
github-actions
bot
force-pushed
the
workflow
branch
2 times, most recently
from
b25f6b8 to
6dd1efd
Compare
github-actions
bot
force-pushed
the
workflow
branch
5 times, most recently
from
f77997d to
bc55824
Compare
github-actions
bot
force-pushed
the
workflow
branch
from
bc55824 to
1d29908
Compare
github-actions
bot
force-pushed
the
workflow
branch
2 times, most recently
from
0e6ebfd to
9ab928a
Compare
github-actions
bot
force-pushed
the
workflow
branch
2 times, most recently
from
2123adf to
d37ddb0
Compare
github-actions
bot
force-pushed
the
workflow
branch
from
d37ddb0 to
ba43a37
Compare
github-actions
bot
force-pushed
the
workflow
branch
2 times, most recently
from
5d04e8d to
b29a924
Compare
github-actions
bot
force-pushed
the
workflow
branch
3 times, most recently
from
e4aa359 to
0e452d2
Compare
github-actions
bot
force-pushed
the
workflow
branch
from
0e452d2 to
d035ebb
Compare
github-actions
bot
force-pushed
the
workflow
branch
from
d035ebb to
25a40e4
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Allowing the timeout blacklist to be disabled has introduced a bug
where a failed connection will not result in the BSS list to be
traversed. This causes IWD to retry the same BSS over and over which
be either a) have some issue preventing a connection or b) may simply
be unreachable/out of range.
This is because IWD was inherently relying on the timeout blacklist
to flag BSS's on failures. With it disabled there was nothing to tell
network_bss_select that we should skip the BSS and it would return
the same BSS indefinitely.
To fix this some of the blacklisting logic was re-worked in station.
Now, a BSS will always get network blacklisted upon a failure. This
allows network.c to traverse to the next BSS upon failure.
For auth/assoc failures we will then only timeout blacklist under
certain conditions, i.e. the status code was not in the temporary
list.
Fixes: 77639d2 ("blacklist: allow configuration to disable the blacklist")
src/station.c | 25 +++++++++++++++++++++----
1 file changed, 21 insertions(+), 4 deletions(-)