Skip to content

Conversation

@IWDTestBot
Copy link
Owner

Currently the netconfig functionality is somewhat separated from
IWD's "connection" process. Regardless if netconfig is enabled
the method return from Connect() will happen after IWD has completed
the 4-way handshake. If netconfig fails its shows externally as an
IWD state change rather than part of the method return from
Connect(). Overall this doesn't pose a significant problem since a
netconfig failure essentially appears as if IWD became disconnected
but more critical is that IWD will not iteratively try more BSS's if
netconfig fails.

For example a BSS may be misconfigured, or not able to communicate to
the DHCP server. IWD could connect to it, and fail netconfig thereby
restarting the autoconnect logic. IWD will then choose the "best" BSS
which may be the one it just failed on. This would then repeat
indefinitely or until a better BSS comes around which could be never.

To improve this netconfig has been adopted into the IWD's BSS retry
logic. If netconfig fails this will not result in IWD transitioning
to a disconnected state, and instead the BSS will be network
blacklisted and the next will be tried. Only once all BSS's have been
tried will IWD go into a disconnected state and start autoconnect
over.

src/station.c | 104 +++++++++++++++++++++++++-------------------------
1 file changed, 51 insertions(+), 53 deletions(-)

jprestwo added 13 commits May 19, 2025 21:45
This is taken care of by the individual cache items and
if none exist, tar fails.
Currently the netconfig functionality is somewhat separated from
IWD's "connection" process. Regardless if netconfig is enabled
the method return from Connect() will happen after IWD has completed
the 4-way handshake. If netconfig fails its shows externally as an
IWD state change rather than part of the method return from
Connect(). Overall this doesn't pose a significant problem since a
netconfig failure essentially appears as if IWD became disconnected
but more critical is that IWD will not iteratively try more BSS's if
netconfig fails.

For example a BSS may be misconfigured, or not able to communicate to
the DHCP server. IWD could connect to it, and fail netconfig thereby
restarting the autoconnect logic. IWD will then choose the "best" BSS
which may be the one it just failed on. This would then repeat
indefinitely or until a better BSS comes around which could be never.

To improve this netconfig has been adopted into the IWD's BSS retry
logic. If netconfig fails this will not result in IWD transitioning
to a disconnected state, and instead the BSS will be network
blacklisted and the next will be tried. Only once all BSS's have been
tried will IWD go into a disconnected state and start autoconnect
over.
Let the caller specify the method timeout if there is an expectation
that it could take a long time.

For the conventional connect call (not the "bssid" debug variant) let
them pass their own callback handlers. This is useful if we don't
want to wait for the connect call to finish, but later get some
indication that it did finish either successfully or not.
Since the method return to Connect() and ConnectBssid() come after
netconfig some tests needed to be updated since they were waiting
for the method return before continuing. For timeout-based tests
specifically this caused them to fail since before they expected
the return to come before the connection was actually completed.
Since netconfig is now part of the Connect() call from a DBus
perspective add a note indicating that this method has the potential
to take a very long time if there are issues with DHCP.
@IWDTestBot
Copy link
Owner Author

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

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

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

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

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

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

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

@IWDTestBot
Copy link
Owner Author

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

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

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

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

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

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

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

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

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

Output:

testSAE

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

@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