Open freedge opened 1 year ago
Yep indeed a bug... SSL_read should be called in a loop, as long as ssl_error == SSL_ERROR_WANT_READ
... but that never happens.
I'm open for suggestions...
Please give it a try with this branch https://github.com/twekkel/htpdate/tree/LargeResponseHeader
hi! thanks for the quick response!
so the branch works a bit better. Note the rc return code is incorrect now (it will return the amount of data sent even if the receive fails).
ntpdate is able to parse a date, but if fails just after:
$ ./htpdate -q https://www.pool.ntp.org -d -c
www.pool.ntp.org 443, 11 May 2023 18:08:54 GMT (183 ms) => 5
www.pool.ntp.org no timestamp
when: 562500000, nap: 500000000
No server suitable for synchronization found
in my case my laptop is not yet synchronized, so htpdate loops, and the second call fails as the connection is closed already. So htpdate only works with -p 1
Using connection: close
breaks every new call as it expects that the connection stays alive... so this is not going to be merged as-is.
Setting up a new connection with each call (especially HTTPS) is more expensive, but probably more safe... will need some more time to investigate and come up with a solid solution.
Some deep digging, thought me a couple of things
connection: close
will immediately flush server data to htpdate, but that would require a new TCP and TLS handshake for each poll (ineffectieve and relative expensive)connection: keep-alive
might require multiple SSL_read actions in a loop as web server doesn't provide the full header in one read... but it you will have the wait in between the the SSL_read actions or else there is no data yetWhen the sleep is commented out at line 250 https://github.com/twekkel/htpdate/blob/e29b49069eb3abaa0c566d71192e0babbeb4db7e/htpdate.c#L250 htpdate might work or not.... introducing the sleep however makes htpdate pretty inaccurate. @freedge please give this update branch a try, with and without sleep.
I'm currently inclined to say that https://www.pool.ntp.org is a poor time source for htpdate and probably the current/original implementation is the best way to go forward.
Not closing this issue, as better solutions might be available...
if the date header does not appear within the first 1024 bytes of the server first response, then it is not parsed at all:
This prevents for example the synchro from https://www.pool.ntp.org, as the date header appears after a bunch of other headers. It would require a bigger buffer and multiple calls to
SSL_read
to work.EDIT: in recent versions of htpdate the BUFFERSIZE was bumped to 8192 but there is still a single call to
SSL_read
so it still fails.