-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Description
While attempting to debug #1707, I was getting mysterious "please start SNTP first" errors. This was confusing, because I am starting SNTP, via sntp.sync(), and even waiting for the all-clear from the callback. Imagine my surprise to discover that the "please start SNTP first" comes from an entirely duplicate implementation of SNTP inside LwIP which, through some closed-source that I cannot trace in libmain.a, is backing mbedtls's notion of the current time (via the time() function), rather than the RTC, yielding "certificate in the future" errors.
Expected behavior
sntp.sync() should set every part of the system's idea of the time.
Actual behavior
There are at least two confused brains inside this thing.
As a hackish workaround, I defined LUA_USE_MODULES_RTCTIME and redefined MBEDTLS_PLATFORM_TIME_MACRO to a function which knows how to get the time from the RTC and removed app/include/lwip/sntp.h, app/include/lwip/app/time.h, and app/lwip/core/sntp.c. This is a link error waiting to happen, but as it happens, isn't right now. ;)
This is a little tricky to get right, because in a sense it means that LUA_USE_MODULES_RTCTIME gates MBEDTLS_HAVE_TIME and such, but the right files aren't included in the right place to do that at the moment.
Possibly the better option is to eliminate app/modules/sntp.c in favor of the LwIP implementation, or to create a shim replacement for the LwIP version that uses the sntp module's internals. Note that the latter option will require a timer to tick every second and keep a software clock up to date (like the LwIP implementation) or the use of the RTC.
Alternatively, we could disable that MBEDTLS_HAVE_TIME and MBEDTLS_HAVE_TIME_DATE so that the TLS implementation does not try to check lifetimes.