`esp_tls_conn_new_async` does not work if real time is set (IDFGH-12594)

[ngc7293]

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.

master

Espressif SoC revision.

ESP32-S2

Operating System used.

Linux

How did you build your project?

Command line with CMake

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

None

Development Kit.

ESP32-S2-DevKitM-1

Power Supply used.

USB

What is the expected behavior?

esp_tls_conn_new_sync waits up to timeout_ms milliseconds before returning (set in the passed esp_tls_cfg_t)

What is the actual behavior?

esp_tls_conn_new_sync returns immediately and logs a warning "Failed to open new connection in specified timeout"

Steps to reproduce.

1. Set the proper time (I used esp_sntp)
2. Call esp_tls_conn_new_sync with timeout_ms = INT32_MAX

Debug Logs.

No response

More Information.

The issue here is that the function's body uses uint32_t to store the epoch timestamp in milliseconds. When the "system" time has not been set this works fine, but if you have properly set the time the current epoch timestamp exceeds the holding capacity of uint32_t.

Additionally, there could be a case where the time is set during the connection process which would also break the timeout check.

The reliance on gettimeofday should probably be replaced with an internal counter, like FreeRTOS's tick count or esp_timer's esp_timer_get_time

See esp_tls.c:542
See gettimeofday

[AdityaHPatwardhan]

Hi @ngc7293 Thanks for finding the issue.
The use of uint32_t type for 64bit time seems wrong. Will make the relevant changes and update here.
Yes and regarding gettimeofday, I see it is better to use esp_timer_get_time at this place which will give a value that shall not be changed.

Thanks,
Aditya

[AxelLin]

@AdityaHPatwardhan
Do you have ETA for the fix? (I think this needs urgent fix for release branches)

[AdityaHPatwardhan]

@AxelLin It is been merged in the internal code-base. Should be available on GitHub in the release branches in a few days.