[Bug] BR_VARIANT was removed from otbr_start.sh in v2.11-beta3.1+fall2024

[angelus-liviu]

Describe the bug

When trying to run tests for Matter1.4 SVE the ble-thread commissioning was failing, after comparing the otbr_start.sh scripts from last TE, Matter1.4 TE#2 and latest image from SVE v2.11-beta3.1+fall2024 I discovered that the BR_VARIANT was removed and this generates a commissioning failing issue.
I updated the script by adding back the BR_VARIANT and seems that this solves the issue.

Steps to reproduce the behavior

Try to execute a test in ble-thread mode with default configuration of TH

Expected behavior

Test to pass successfully

Log files

otbr_start_SVE.txt
otbr_start_TE2.txt
otbr_start_original.txt

PICS file

No response

Screenshots

No response

Environment

TH v2.11-beta3.1+fall2024

Additional Information

Attached you can find:
otbr_start_TE2.txt -> the script from Matter1.4 TE#2
otbr_start_SVE.txt -> the script modified with BR_VARIANT added
otbr_start_original -> the script from v2.11-beta3.1+fall2024 unmodified

[antonio-amjr]

Hi @angelus-liviu,

Can you share your project's configuration for this test?

Since there are changes in the OTBR script, the project's thread configuration should match the thread values within the script.
I believe the idea of the new otbr_start is to be the same as the default project configuration that TH has initially, and you may always use variants changing the thread values (BR_CHANNEL, BR_PANID, etc.) as desired, on both script and project configuration.

[angelus-liviu]

Hi @antonio-amjr ,

The TH project configuration is the following one:
"{
"config": {
"test_parameters": null,
"network": {
"wifi": {
"ssid": "testharness",
"password": "wifi-password"
},
"thread": {
"rcp_serial_path": "/dev/ttyACM0",
"rcp_baudrate": 115200,
"on_mesh_prefix": "fd11:34::/64",
"network_interface": "eth0",
"dataset": {
"channel": "15",
"panid": "0x5b34",
"extpanid": "5b34dead5b34beef",
"networkkey": "00112233445566778899aabbccddeeff",
"networkname": "5b34"
},
"otbr_docker_image": null
}
},
"dut_config": {
"discriminator": "884",
"setup_code": "20202021",
"pairing_mode": "ble-thread",
"chip_timeout": null,
"chip_use_paa_certs": false,
"trace_log": true
}
},"
So I modified the TH project's thread configuration to match the thread values within the script.
And after making those changes in the TH project configuration the tests are passing even with the TH.

[antonio-amjr]

Hi @angelus-liviu,

Glad that everything worked out, but please let me clarify about the thread commissioning options. It seems that you're using a mix of the two options.

---

When using the BLE-Thread mode, basically we have two scenarios of configuration, one using an external OTBR and the other TH automatically creating a OTBR. So our options are:

1. For the External OTBR, you may use the otbr_start.sh script for that, but the project configuration should use the operational dataset from the script output as shown below:

{
...
      "thread": {
        "operational_dataset_hex": "0e08000000000001000035060004001fffe00708fd7476b97cb057ff0410e8d301fa43cb3eaddc4a231722388ca00c0402a0f7f8000300000f0102123402081111111122222222030444454d4f051000112233445566778899aabbccddeeff"
      }
...
}

Example of otbr start script dataset output

2. For the automatic OTBR, we don't need to run any script or external script since TH is responsible for creating the OTBR with the Thread information similar with the default configuration shown below:

{
...
      "thread": {
         "rcp_serial_path": "/dev/ttyACM0",
         "rcp_baudrate": 115200,
         "on_mesh_prefix": "fd11:22::/64",
         "network_interface": "eth0",
         "dataset": {
            "channel": "15",
            "panid": "0x1234",
            "extpanid": "1111111122222222",
            "networkkey": "00112233445566778899aabbccddeeff",
            "networkname": "DEMO"
         },
         "otbr_docker_image": null
      }
...
}

---

That explained, in your case I believe you don't need to use the otbr_start.sh script the way you are configuring the TH project.
Feel free to test it out, let me know any problem you're facing, and if no issue is encountered please close this issue.

PS: You may verify this information with more details in the TH User Guide's Thread Device Mode section.

[angelus-liviu]

Hi @antonio-amjr

Thank you for clarifying the options. I initially thought that the otbr_start.sh script was also used for the TH configuration. Now everything is clear, but the main issue is that the BR_VARIANT has been removed from the latest version of the otbr_start.sh script.
I understand the reason for this change (to align with the TH configuration parameters), but removing it results in the same Thread configuration. In an environment with multiple OTBRs, this can cause conflicts due to identical network parameters. Therefore, I believe the BR_VARIANT should be reinstated in the script.
I’ll keep the issue open for now.

[antonio-amjr]

Hi @angelus-liviu,

I think I got it now.
In an environment of multiples OTBRs it's important to have a mechanism to easily vary the Thread configuration, is that correct?

I'm not opposed to roll back to the previous version then. Just one question, an improvement suggestion.
Since it's common to vary the config, would be good to have the option to change the BR_VARIANT as a script parameter?
Like the example below:
./otbr_start.sh --variant 45

[antonio-amjr]

Hi @angelus-liviu,

A opened a PR to revert the OTBR start script and use BR_VARIANT once again:
project-chip/certification-tool-backend#150

I also included the suggestion to use switch parameters with the script.