Skip to content

Conversation

@IWDTestBot
Copy link
Owner

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(-)

jprestwo added 18 commits March 7, 2025 16:32
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 adds a new (less severe) 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.

Now that we have multiple blacklist reasons there may be situations
where a blacklist entry already exists but with a different reason.
This is going to be handled by the reason severity. Since we have
just two reasons we will treat a connection failure as most severe
and a roam requested as less severe. This leaves us with two
possible situations:

1. BSS is roam blacklisted, then gets connection blacklisted:
   The reason will be "promoted" to connection blacklisted.

2. BSS is connection blacklisted, then gets roam blacklisted:
   The blacklist request will be ignored
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.

This then allows IWD to consider this blacklist state when picking
a roam candidate. Its undesireable to fully ban a roam blacklisted
BSS, so some additional sorting logic has been added. Prior to
comparing based on rank, BSS's will be sorted into 3 groups:

Optimal - Not roam blacklisted, and above the roaming threshold
Above Threshold - May be blacklisted, and above the roaming threshold
Below Threshold - BSS is below the roaming threshold
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.
@IWDTestBot
Copy link
Owner Author

Fetch PR
Test ID: fetch
Desc: Fetch the PR commits for this CI run
Duration: 3.10 seconds
Result: PASS

Prep - Setup ELL
Test ID: setupell
Desc: Clone, build, and install ELL
Duration: 25.92 seconds
Result: PASS

Make Distcheck
Test ID: makedistcheck
Desc: Run distcheck to check the distribution
Duration: 55.38 seconds
Result: PASS

Build - Configure
Test ID: build
Desc: Configure the BlueZ source tree
Duration: 12.70 seconds
Result: PASS

Make Check
Test ID: makecheck
Desc: Run 'make check'
Duration: 2.61 seconds
Result: PASS

Make Check w/Valgrind
Test ID: makecheckvalgrind
Desc: Run 'make check' with Valgrind
Duration: 103.65 seconds
Result: PASS

Incremental Build with patches
Test ID: incremental_build
Desc: Incremental build per patch in the series
Duration: 467.90 seconds
Result: PASS

@IWDTestBot
Copy link
Owner Author

Fetch PR
Test ID: fetch
Desc: Fetch the PR commits for this CI run
Duration: 2.59 seconds
Result: PASS

GitLint
Test ID: gitlint
Desc: Run gitlint with rule in .gitlint
Duration: 12.63 seconds
Result: PASS

Prep - Setup ELL
Test ID: setupell
Desc: Clone, build, and install ELL
Duration: 30.80 seconds
Result: PASS

Make Distcheck
Test ID: makedistcheck
Desc: Run distcheck to check the distribution
Duration: 38.23 seconds
Result: PASS

Build - Configure
Test ID: build
Desc: Configure the BlueZ source tree
Duration: 22.71 seconds
Result: PASS

Make Check
Test ID: makecheck
Desc: Run 'make check'
Duration: 3.48 seconds
Result: PASS

Make Check w/Valgrind
Test ID: makecheckvalgrind
Desc: Run 'make check' with Valgrind
Duration: 122.56 seconds
Result: PASS

Incremental Build with patches
Test ID: incremental_build
Desc: Incremental build per patch in the series
Duration: 495.34 seconds
Result: PASS

Autotest Runner
Test ID: testrunner
Desc: Runs IWD's autotest framework
Duration: 1801.04 seconds
Result: FAIL

Output:

testPSK-roam

Clang Build
Test ID: clang
Desc: Build IWD using clang compiler
Duration: 124.60 seconds
Result: PASS

@github-actions github-actions bot force-pushed the workflow branch 2 times, most recently from 6a6b0cc to 55901fd Compare April 1, 2025 16:34
@github-actions github-actions bot force-pushed the workflow branch 3 times, most recently from a2c9985 to 624cea8 Compare April 23, 2025 14:49
@github-actions github-actions bot force-pushed the workflow branch 4 times, most recently from 4df9cf3 to 38db487 Compare May 5, 2025 18:50
@github-actions github-actions bot force-pushed the workflow branch 3 times, most recently from f77997d to bc55824 Compare May 7, 2025 12:14
@github-actions github-actions bot force-pushed the workflow branch 2 times, most recently from 0e6ebfd to 9ab928a Compare May 28, 2025 17:40
@github-actions github-actions bot force-pushed the workflow branch 2 times, most recently from 2123adf to d37ddb0 Compare June 5, 2025 15:31
@github-actions github-actions bot force-pushed the workflow branch 2 times, most recently from 5d04e8d to b29a924 Compare August 7, 2025 23:01
@github-actions github-actions bot force-pushed the workflow branch 3 times, most recently from e4aa359 to 0e452d2 Compare August 26, 2025 15:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants