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

chip-tool scans for BLE devices when it should not #21664

Closed
bluebin14 opened this issue Aug 5, 2022 · 7 comments · Fixed by #22104
Closed

chip-tool scans for BLE devices when it should not #21664

bluebin14 opened this issue Aug 5, 2022 · 7 comments · Fixed by #22104
Assignees
Labels
commissioning Involves placing devices on the network, initial setup request sve

Comments

@bluebin14
Copy link
Contributor

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.

@bluebin14 bluebin14 added commissioning Involves placing devices on the network, initial setup request sve labels Aug 5, 2022
@bzbarsky-apple bzbarsky-apple removed their assignment Aug 5, 2022
@bzbarsky-apple
Copy link
Contributor

@vivien-apple Any objections to changing pairing code to munge the onboarding payload to just set the "on-network" flag in its discovery bitmap?

@bluebin14
Copy link
Contributor Author

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.

@bzbarsky-apple
Copy link
Contributor

@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.

@bluebin14
Copy link
Contributor Author

Having a yaml fix is good as long as chip-tool itself is usable in a mode that skips BLE scanning.

@woody-apple
Copy link
Contributor

Cert Blocker Review: @cjandhyala to figure out if this is blocking test cases.

@cjandhyala
Copy link
Contributor

cjandhyala commented Aug 19, 2022

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
Copy link
Contributor

@vivien-apple Any objections to changing pairing code to 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
commissioning Involves placing devices on the network, initial setup request sve
Projects
None yet
5 participants