-
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
[K32W] Failure during the BLE Rendezvous session #7320
Comments
It doesn’t seem that the controller is getting the OpCSR response from the DUT. I can see the DUT did send a message. Can you add more logs in this function to make sure that it did the correct response?
The function has logs for error scenarios, but not sure if those are not getting printed for some reason. For reference, we should see some of the following logs on the controller side when it receives the OpCSR.
|
Thanks @pan-apple for helping me. I step into emberAfOperationalCredentialsClusterOpCSRRequestCallback and it returns with success. Then I took a closer look at the logs on the chip-device-ctrl-side:
So there are some indications that are being received from the device side. Then I looked into the device side, and these indications are being sent immediately after the CSR Op Rsp is generated, so they should contain DER bytes. As long as the SPAKE2+ session was successful, I don't expect that BLE transport lost any byte. Here are the relevant logs on the device side (first I print the DER bytes inside emberAfOperationalCredentialsClusterOpCSRRequestCallback then I print the BLE bytes in BLEManagerImpl.cpp):
|
After several hours of debugging I found an workaround:
The initial value for the mResponseTimeout is 30000 (30s?), but the timeout error occurs after 20s - I don't understand why. @pan-apple any idea? |
That's really weird. Does doubling it change it to 40s? It would indicate some issue with the timer itself. |
With the default value, the timer always expires in the middle of the CSR response reception - this happens after ~16-17s after the "connect -ble" is issued. However, it's unclear to me if the timer is armed for the whole rendezvous session or only for the CSR response. |
This timer issue seems to be related to #7005: the embedded device sent the required packets but the chip-device-ctrl times out. @pan-apple could you please help me with adding some debug code? I was thinking to print a timestamp when the timer is armed then a timstamp when the timer expires. It's unclear to me when the timer is armed. |
@doru91 , I think this function is setting up the response timer
specifically, here
Looks like the default timeout is 6 seconds.
|
Perfect, @pan-apple . Submitted #7490 |
Is this resolved? |
SPAKE2+ session is successful. Then the commissioner sends a CSR Request to the DUT, it looks like the DUT replies with a CSR Request Response but the chip-device-ctrl looks to timeout the message.
Head is at
I checked with other vendors and everything is ok on their side. I expect that there is a problem on the DUT side. Any help on how to debug this would be appreciated.
Logs on the device side:
Logs on the chip-device-ctrl side:
cc @pan-apple
The text was updated successfully, but these errors were encountered: