-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
chip-tool scans for BLE devices when it should not #21664
Comments
@vivien-apple Any objections to changing |
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 |
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. |
Instead of munging the QRcode I change the code in |
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.
The text was updated successfully, but these errors were encountered: