Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] [NetworkCommissioning] Empty results of directed ScanNetworks don't return expected NetworkNotFoundError #31870

Closed
Survensa opened this issue Feb 2, 2024 · 0 comments · Fixed by #32156
Assignees
Milestone

Comments

@Survensa
Copy link

Survensa commented Feb 2, 2024

Feature Area

Other

Test Case

TC-CNET-4.4

Reproduction steps

  1. Bring up the Device Under Test (DUT) with the all-clusters-app.
  2. Pair the DUT using chip-tool through the "ble-wifi" transport.
  3. Scan the network to know available networks : ./chip-tool networkcommissioning scan-networks 1 0 --Ssid null --Breadcrumb 1
    Note : Select any one SSID as 1ST_ACCESSPOINT_SSID_hex
  4. Scan the selected network : ./chip-tool networkcommissioning scan-networks 1 0 --Ssid hex:<1ST_ACCESSPOINT_SSID_hex> --Breadcrumb 2
  5. Turn off the 1ST_ACCESSPOINT_SSID_hex wifi
  6. Now scan the selected network to expect the NOT FOUND error

Test Plan Expected outcome :

_Verify that the DUT sends the ScanNetworkResponse command with the NetworkingStatus field set to NetworkNotFound._

Expected outcome:

[1683268296.897526][12131:12134] CHIP:TOO: NetworkConfigResponse: {
[1683268296.897745][12131:12134] CHIP:TOO: networkingStatus: 3
[1683268296.898546][12131:12134] CHIP:TOO: }

Actual outcome:

[1707212325.045487][39892:39895] CHIP:TOO: ScanNetworksResponse: {
[1707212325.045576][39892:39895] CHIP:TOO: networkingStatus: 0
[1707212325.045644][39892:39895] CHIP:TOO: wiFiScanResults: 0 entries
[1707212325.045886][39892:39895] CHIP:TOO: }

Bug prevalence

Whenever I do this

GitHub hash of the SDK that was being used

f63b505

Platform

raspi

Logs:
TC_CNET_4_4(ctrl).txt
TC_CNET_4_4(dut).txt

Test Plan Reference: https://github.com/CHIP-Specifications/chip-test-plans/blob/master/src/cluster/network_commissioning.adoc#tc-cnet-4-4-wi-fi-verification-for-scannetworks-command-dut-server

@Survensa Survensa added bug Something isn't working cert blocker needs triage labels Feb 2, 2024
@tcarmelveilleux tcarmelveilleux self-assigned this Feb 8, 2024
@tcarmelveilleux tcarmelveilleux changed the title [CERT-TEST-FAILURE] - TC-CNET-4.4 - Test failed [Bug] [NetworkCommissioning] Empty results of directed ScanNetworks don't return expected NetworkNotFoundError Feb 8, 2024
@tcarmelveilleux tcarmelveilleux added this to the 1.3 SVE milestone Feb 8, 2024
tcarmelveilleux added a commit to tcarmelveilleux/connectedhomeip that referenced this issue Feb 15, 2024
This PR addresses several NetworkCommissioning issues
which are all inter-related:

- Attributes are never reported on change.
- ScanNetworks used to modify attributes that should not be modified
- LastNetworkStatus was not set where required
- Thread network scanning did not report error on SSID field provided
- All ConstraintErrors actually were reported as InvalidCommand
- Lacking results of directed scanning did not report NetworkNotFound

- Fixes project-chip#32024
- Fixes project-chip#32022
- Fixes project-chip#32021
- Fixes project-chip#32019
- Fixes project-chip#32018
- Fixes project-chip#31870

Testing done:
- TC-CNET-4.4 pass on ESP32 and Linux
- Commissioning works on ESP32 and Linux
- Manual testing of all attribute changes validated with chip-repl
  - Automated test beyond TC-CNET-4.4 coming as a follow-up
@mergify mergify bot closed this as completed in #32156 Feb 16, 2024
@mergify mergify bot closed this as completed in a04f478 Feb 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants