[TC-CNET-4.9] Test case get fails in UI

[KishokG]

Describe the bug

TC-CNET-4.9 test case is failing in step 2, 4, 7, 8, 10, 12, 14.

Steps to reproduce the behavior

1. From the Test-Harness user interface loaded the Network Commissioning Test Plan(WiFi).xml PICS file to select the test cases.
2. Selected the TC-CNET-4.9 Semi-Automated test case to executed.
3. Executed the below mentioned command to put DUT into a commissionable state, ./chip-all-clusters-app --wifi
4. Click the Start button on Test-Harness user interface.

Expected behavior

TC should execute successfully without error.

Log files

CNET-4_9_2023_12_13_16_58_50.log

Report: TC-CNET-4.9.pdf

PICS file

Network Commissioning Test Plan(WiFi).zip

Screenshots

Environment

Version: main - dev Sha: f17efc4

[antonio-amjr]

Hi @KishokG,

Analyzing the erros in the logs I noticed some results entries with 'NetworkID': b'GRLPrivate' while the expected value is 'NetworkID': b'zigbeehome'. That happens because the default value for the SSID name is indeed "zigbeehome" as you can see below:

# TC-CNET-4.9 YAML file
config:
    nodeId: 0x12344321
    cluster: "Network Commissioning"
    endpoint: 0
    PIXIT.CNET.WIFI_1ST_ACCESSPOINT_SSID:
        type: octet_string
        defaultValue: "hex:7A6967626565686F6D65" # zigbeehome in hex string

Can you try something for me? Try editing the project's config file, changing "test_parameters" to the following:

"test_parameters": {
      "PIXIT.CNET.WIFI_1ST_ACCESSPOINT_SSID": "hex:47524C50726976617465"
    }

The value "hex:47524C50726976617465" is equivalent to the string GRLPrivate.

Let me know the results.

[KishokG]

@antonio-amjr As per your instruction I ran the test case and now it's failing in step 12 and 14. Because after disarming the fail safe, the network should be connected in PIXIT.CNET.WIFI_1ST_ACCESSPOINT_SSID. But in UI it's not connecting to the PIXIT.CNET.WIFI_1ST_ACCESSPOINT_SSID after disarming the fail safe.

I ran this test case manually using TH image sample app and SDK and it's passing.

Here is the TH image log and report: CNET-4_9_2023_12_15_09_47_44.log TC-CNET-4.9_report.pdf

Manual ran Logs: TC-CNET-4.9_chip-tool.txt TC-CNET-4.9_DUT.txt

[antonio-amjr]

Thanks for the reply @KishokG, I'll have to look into it. Meanwhile, could you send me the DUT's log from the TH UI execution as well?

[antonio-amjr]

Hi @KishokG, I didn't manage to test this unfortunately, since I don't have two RaspberryPi for the BLE-WiFi pairing mode. Did you have the chance to gather the DUT's from the TH UI so I could take a look?

[KishokG]

Hi @antonio-amjr Here is the DUT 's log: TC-CNET-4.9_DUT_TH_UI.txt

[antonio-amjr]

Hello again @KishokG,

Analyzing the TH UI DUT's log, the only thing that caught my eyes was the following error: wpa_supplicant: failed to save config: GDBus.Error:fi.w1.wpa_supplicant1.UnknownError: Not allowed to update configuration (update_config=0)

I was wondering if this is related to the network connection not coming back since update_config is disable and it didn't manage to save the configuration.

From the manual run DUT's log, this operation was a success with the following: wpa_supplicant: save config succeeded!

So, If you haven't already, please try the instructions from the doc for the wpa_supplicant config in the link below: Enable WiFi supplicant permission in Ubuntu server

[antonio-amjr]

Hi @KishokG,

Did you have the chance to verify the above? Let me know if I can help.

Thanks

[KishokG]

Hi @antonio-amjr Sorry for the delayed response. Will check and let you know the status

[KishokG]

As per the above instructions updated the wpa_supplicant config file and now the test case is passing.

Thank you @antonio-amjr