Commissioning fails on a slow CPU

[ktaylor-meus]

Because our CPU is slow, we are failing the commissioning process (timeouts), unless we can stretch the timeouts further.
This happens primarily on the routines to do ECC functions, and the wrappers around those.
Once commissioned, everything works fine - it's just getting through the certificate validation.

architecture
STM32F @24 MHz
Wifi/Bluetooth/no Thread
Thermostat Server
FreeRTOS 9.0, WICED SDK 3.3

The following changes solved it for us. The problem, of course, is interactions with 3rd party devices which use the original timing.
I don't know if this counts as a bug or a feature request...
Commented lines are thr original values, uncommented are our changes.

src/messaging/ReliableMessageProtocolConfig.h
#define CHIP_CONFIG_MRP_DEFAULT_INITIAL_RETRY_INTERVAL (15000)
//#define CHIP_CONFIG_MRP_DEFAULT_INITIAL_RETRY_INTERVAL (5000)

src/protocols/secure_channel/CASESession.cpp
static constexpr ExchangeContext::Timeout kSigma_Response_Timeout = System::Clock::Seconds16(30);
//static constexpr ExchangeContext::Timeout kSigma_Response_Timeout = System::Clock::Seconds16(10);

src/protocols/secure_channel/PASESession.cpp
// no change required
static constexpr ExchangeContext::Timeout kSpake2p_Response_Timeout = System::Clock::Seconds16(30);

src/controller/CHIPDeviceController.cpp
constexpr uint32_t kSessionEstablishmentTimeout = 500 * kMillisecondsPerSecond;
//constexpr uint32_t kSessionEstablishmentTimeout = 30 * kMillisecondsPerSecond;

src/include/platform/CHIPDeviceConfig.h
#define CHIP_DEVICE_CONFIG_DISCOVERY_TIMEOUT_SECS 15 * 60
//#define CHIP_DEVICE_CONFIG_DISCOVERY_TIMEOUT_SECS 3 * 60

[woody-apple]

These seem like reasonable extensions to the minimum time?

[msandstedt]

With regard to MRP, it appears the sdk isn't actually honoring the idle retry interval at all. So tweaks there won't do much. The sdk also isn't adding the random, exponential backoff the spec requires.

Do we have a ticket specifically for the MRP component of this?

[ktaylor-meus]

The ticket was originally opened against the test-event-7 source. In test-event-7.5, it appears to work in a more open-ended fashion, and is correct for us. This may already be fixed… Kit From: Michael Sandstedt ***@***.***> Sent: Tuesday, March 1, 2022 2:59 PM To: project-chip/connectedhomeip ***@***.***> Cc: Taylor, Kit ***@***.***>; Author ***@***.***> Subject: Re: [project-chip/connectedhomeip] Commissioning fails on a slow CPU (Issue #12680) With regard to MRP, it appears the sdk isn't actually honoring the idle retry interval at all. So tweaks there won't do much. The sdk also isn't adding the random, exponential backoff the spec requires. Do we have a ticket specifically for the MRP component of this? — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/project-chip/connectedhomeip/issues/12680*issuecomment-1055805496__;Iw!!Fz2TSg!Il5PJJWIW6PPNEmHy4ilvozOZsAONWnxpEfx27X1hgc6h9PgUJnbHFTY3NGwchQO$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AUP3OVRD3EYG64ALWN66PJLU5ZZHZANCNFSM5JRRVBZQ__;!!Fz2TSg!Il5PJJWIW6PPNEmHy4ilvozOZsAONWnxpEfx27X1hgc6h9PgUJnbHFTY3CAHCtr_$>. Triage notifications on the go with GitHub Mobile for iOS<https://urldefense.com/v3/__https:/apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!Fz2TSg!Il5PJJWIW6PPNEmHy4ilvozOZsAONWnxpEfx27X1hgc6h9PgUJnbHFTY3N8anH5I$> or Android<https://urldefense.com/v3/__https:/play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!Fz2TSg!Il5PJJWIW6PPNEmHy4ilvozOZsAONWnxpEfx27X1hgc6h9PgUJnbHFTY3LI4fvj7$>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[bzbarsky-apple]

So the current state of things here, compared to when the issue was filed, is:

1. The MRP params used will be whatever the device advertises. Backoff is now implemented.
2. kSigma_Response_Timeout is set to 30s, since Increase CASE timeout to fix CI failures #11435.
3. kSessionEstablishmentTimeout is now 40s.
4. Important: Per-command timeouts during commissioning are now at least 30s, so the crypto that happens there has time to happen.
5. CHIP_DEVICE_CONFIG_DISCOVERY_TIMEOUT_SECS is now 15*60 by default. In any case, this is configurable by the app when it builds.

that looks like all the initial proposals except for setting kSessionEstablishmentTimeout to "500s" have happened now. And that one was raised to 40s.

@ktaylor-meus You said above that things are working on your end now. Can this just be closed?

[ktaylor-meus]

The fixes mentioned above did take care of most of our issues (as mentioned above). The last issue was the time it takes our CPU to do the ECC calculations. We finally got the go-ahead from our management to add a ECC chip to do those, so no problems remain. This can be closed. I don’t see right off how to do that (I’m new to github), so hopefully some else has access to close it. Thanks for the help. Kit From: Boris Zbarsky ***@***.***> Sent: Friday, June 10, 2022 4:15 PM To: project-chip/connectedhomeip ***@***.***> Cc: Taylor, Kit ***@***.***>; Mention ***@***.***> Subject: Re: [project-chip/connectedhomeip] Commissioning fails on a slow CPU (Issue #12680) So the current state of things here, compared to when the issue was filed, is: 1. The MRP params used will be whatever the device advertises. Backoff is now implemented. 2. kSigma_Response_Timeout is set to 30s, since #11435<https://urldefense.com/v3/__https:/github.com/project-chip/connectedhomeip/pull/11435__;!!Fz2TSg!aEciKgSCJewP_oMQi1lylb33sHP9K6wayy_G4qgZOELfFwPCbHSpAxHFcdph2Hm6WjHAn_9IzBhK2liHZY4mbckDBw$>. 3. kSessionEstablishmentTimeout is now 40s. 4. Important: Per-command timeouts during commissioning are now at least 30s, so the crypto that happens there has time to happen. 5. CHIP_DEVICE_CONFIG_DISCOVERY_TIMEOUT_SECS is now 15*60 by default. In any case, this is configurable by the app when it builds. that looks like all the initial proposals except for setting kSessionEstablishmentTimeout to "500s" have happened now. And that one was raised to 40s. @ktaylor-meus<https://urldefense.com/v3/__https:/github.com/ktaylor-meus__;!!Fz2TSg!aEciKgSCJewP_oMQi1lylb33sHP9K6wayy_G4qgZOELfFwPCbHSpAxHFcdph2Hm6WjHAn_9IzBhK2liHZY5AQqdDXg$> You said above that things are working on your end now. Can this just be closed? — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/project-chip/connectedhomeip/issues/12680*issuecomment-1152704561__;Iw!!Fz2TSg!aEciKgSCJewP_oMQi1lylb33sHP9K6wayy_G4qgZOELfFwPCbHSpAxHFcdph2Hm6WjHAn_9IzBhK2liHZY40OMO5CQ$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AUP3OVUJMU66LSEOVHIZK2DVOOO33ANCNFSM5JRRVBZQ__;!!Fz2TSg!aEciKgSCJewP_oMQi1lylb33sHP9K6wayy_G4qgZOELfFwPCbHSpAxHFcdph2Hm6WjHAn_9IzBhK2liHZY4cZe2GJg$>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[bzbarsky-apple]

@ktaylor-meus Thank you for following up!