Commissioning timeout not reported to application #15409
Comments
caipiblack
changed the title
|
Note that the problem of the So most of the times, when pairing fails we have to reboot the software/stack/commissioner. |
|
@tehampson Did #17778 fix this by any chance? |
|
What I know is that on TE9 commit, we still have an issue when we reproduce what I said but it's possibly not the same problem!
|
|
That error happens if someone calls @caipiblack is your code still calling into this API: ? Are you seeing "Invalid device for commissioning" before that error? In general, attaching (not pasting, please) a log would be useful here. |
|
This is how the commissioning is made in my application: Yes when I re-start the commissioning I get the error Note that the NodeId is incremented between the two tries and the device is resetted. Attached you will find full logs: logs-double-commissioning.txt And here the logs of the second comissioning: Edit: It can be reproduced using linux |
Perfect. This indeed reproduces things for me. So what happens is that we land in Then we check Since IsSecureConnected() is true, Now we call Now if on the second commissioning we passed in node id 1, not 2, then we would get past this point but then we still think we have a PASE session, but we actually do not, that would time out. And if I don't reset the device, so the BLE session is still alive, I get #19138 which needs to get sorted out separately. Anyway, one obvious thing we should do is drop the existing device in |
Found during investigation of project-chip#15409 but there may be more problems left in that issue. If we get into EstablishPASEConnection and find an existing commissionee for the peer address (which is easy for BLE, where the peer address is basically a singleton), but the device id does not match the passed-in one, we should not reuse that device. If we try to, Commission will fail to find the commissionee device by device id and fail out.
|
#19141 makes the "try again with a different device id" case work, at least. |
) Found during investigation of #15409 but there may be more problems left in that issue. If we get into EstablishPASEConnection and find an existing commissionee for the peer address (which is easy for BLE, where the peer address is basically a singleton), but the device id does not match the passed-in one, we should not reuse that device. If we try to, Commission will fail to find the commissionee device by device id and fail out.
|
Today during the commissioning of a thread device it has failed at the step 18: Once we get this error, all subsequent pairing was failing: But now I think it's more related to this issue generic issue : #16868 |
When trying to pair with the same node id, or a different one? Note that the comment in #16868 talks about the "TE9 commit", which does not have the fix from #19141.... Again, that fix should make things work as long as a new node id is used. |
|
I can confirm that your fix solve the problem in my case (as I increment the nodeId on each commissioning even if it fails). |
|
Issue Scrub: Looks like this is resolved, closing. Please re-open if this is still an issue. |
Problem
Commit: b0af6ba (Tue Jan 4 02:17:19 2022 +0100)
When I start a BLE-WIFI commissioning with incorrect ssid or password, there is no timeout or callback triggered in application side and the commissioning sessions is not cleaned.
Code:
When the ssid and password are correct, everything is good.
When the ssid and password are wrong the device try to connect to WiFi network and fail, on the commissioner side,
OnSessionEstablishmentTimeout()is never called, soStopPairing()andmPairingDelegate->OnPairingComplete(CHIP_ERROR_TIMEOUT)are never called.The result is:
void OnPairingComplete(CHIP_ERROR err)is not called)StopPairing()is also never calledFreeRendezvousSession()is never called, so we can't start another pairing until the end of the first oneSome kind of timeout is detected because BLE connexion is closed but the application is not notified and the "RendezvousSession" is not cleaned.
Here some logs:
ble_wifi_wrong_ssid.log
The text was updated successfully, but these errors were encountered: