esp_dpp: crash when calling esp_supp_dpp_deinit then init again without delay (IDFGH-9524) (IDFGH-9525)

[jasta]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v4.4.4 and v5.0.1

Operating System used.

Linux

How did you build your project?

Other (please specify in More Information)

If you are using Windows, please specify command line type.

None

Development Kit.

ESP32-C3-DevKit-M-1

Power Supply used.

USB

What is the expected behavior?

esp_supp_dpp_deinit then esp_supp_dpp_init should work without crash and behave functionally the same as the first time it is init. This is especially important as we must use this workaround until #10865 is merged in master (i.e. you cannot simply call esp_supp_dpp_start_listen to resume after an error). The effect of these two issues combined is that any error at all, including user error, is fatal to the MCU with respect to DPP and the device must be rebooted to try provisioning again.

What is the actual behavior?

High probability of a crash, due to the following race condition:

Caller Task	dppT Task #1	dppT Task #2
dpp_init()
	xQueueReceive (blocked)
dpp_deinit()
	Handling SIG_DPP_DEL_TASK
dpp_init()
		xQueueReceive (blocked)
	s_dpp_evt_queue = NULL;
		xQueueReceive crashes: s_dpp_evt_queue is NULL

Steps to reproduce.

Minimum steps to reproduce are simply:

while (true) {
  esp_supp_dpp_init(...);
  esp_supp_dpp_bootstrap_gen(...);
  vTaskDelay(10);
  esp_supp_dpp_deinit();
}

Usually will crash after 2 or 3 iterations of the loop.

The dpp-enrolle example can be modified to simply do it's initializing in a while (true) { ... } loop. Replace xEventGroupWaitBits with vTaskDelay.

Debug Logs.

https://gist.github.com/a067c88e511dfff52e7f704d469e157f

More Information.

I used Rust when I first discovered the bug, but can confirm it repros even in a modified dpp-enrollee example. For the Rust support, see esp-rs/esp-idf-sys#168.

[jgujarathi]

Hi @jasta,
We have not been successful in reproducing the issue on the mentioned IDF releases.
If you are still able to reproduce the issue can you please share a basic patch for the WiFi Easy Connect example?

Thanks!

[jasta]

I won't have time soon to retest, I abandoned using wifi dpp due to multiple quality issues found in esp32's implementation (as one example see the linked task in the description for an even more severe issue). That said, the race condition I identified can be proven statically as shown in the table above in this task (i.e. as a thought experiment if you translated that code to Rust the Rust compiler would happily be able to show the code to not be thread safe). At any rate, I'm fine closing this task with a will not fix status so others can more quickly draw the same conclusion I did about quality issues.

FWIW, I'd probably rather see esp-idf eventually just make the wpa_supplicant / wifi support a separate module entirely and give space for the wider community to maintain an updated version with more features and a higher quality esp-specific implementation. The new wpa_supplicant has so many extra features like wifi direct, more robust dpp support, numerous bug fixes, etc.

[Sherry616]

Thanks for reporting, we will close this issue as it is not reproducible. Feel free to reopen if have more updates.