connectedhomeip
connectedhomeip copied to clipboard
project-chip
chip-tool scans for BLE devices when it should not
Problem
After opening a commisioning window chip-tool is used as a new commissioner to scan for the device. As per spec this can only be done on IP network, yet chip-tool scans primarily for BLE wasting a great amount of bandwith and log output, interfering with the purpose of the command. The command used is "chip-tool pairing code".
Proposed Solution
Fix "chip-tool pairing code" so that it does not scan for BLE unless Thread credentials are provided. The reason: see above, plus without network credentials the commissioning would fail anyway.
@vivien-apple Any objections to changing pairing code to munge the onboarding payload to just set the "on-network" flag in its discovery bitmap?
Note that the QR code shipping with Thread devices will have the BLE flag set. The same QR code should be still usable however when opening basic commissioning window, which obviously needs IP. Since at that point the device is already on IP, obeying the BLE flag would cause definite failure. The only way to reuse the QR code: if no network credentials provided then ignore BLE flag, even if it is set.
@bluebin14 SetUpCodePairer always does on-network discovery, no matter what, because the spec says to do that. So "obeying the BLE flag" is not a problem.
Per Slack discussion, by the way, this issue has nothing to do with "pairing code". This is about the behavior of the test PairWithCode command in YAML.
Having a yaml fix is good as long as chip-tool itself is usable in a mode that skips BLE scanning.
Cert Blocker Review: @cjandhyala to figure out if this is blocking test cases.
per conversation with @bluebin14 , the issue happens when running with a bunch of devices doing BLE advertising in a lab environment, the pairing with code command is spending too much time in BLE scanning, when it is not necessary to do BLE scanning because when the DUT is in commissioning mode after opening window with ECM/BCM, chip-tool should scan only on IP transport and not required to scan BLE adv. This is not an issue if they have 1-2 devices around.
The suggested fix was, to fix pairing with code cmd in the chip-tool not scan for ble unless the user provides BLE/thread credentials.
@vivien-apple Any objections to changing
pairing codeto munge the onboarding payload to just set the "on-network" flag in its discovery bitmap?
Instead of munging the QRcode I change the code in SetUpCodePairer.cpp to not scan over BLE if no credentials are provided.
With #22104 I would expect both the YAML issue and the chip-tool command to works as requested here.
