Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NTPClient object sets time to 2036-02-07 #84

Open
jnew123 opened this issue Dec 5, 2019 · 7 comments · May be fixed by #211
Open

NTPClient object sets time to 2036-02-07 #84

jnew123 opened this issue Dec 5, 2019 · 7 comments · May be fixed by #211
Labels
topic: code Related to content of the project itself type: imperfection Perceived defect in any part of project

Comments

@jnew123
Copy link

jnew123 commented Dec 5, 2019

I'm using the NTPClient in an arduino project.

Yesterday right after 19:40:53 CET the clock jumped to 2036-02-07 07:28:16. The object continued from this date on for about 2 more minutes until 2036-02-07 07:29:38 then it came back again to current time: 2019-12-04 19:42:18.

Does anyone know what might be the issue?

Based on this thread, which is quite related to this problem but with a different library, seems to be an internet connectivity issue. However why does the clock go to the future?

I am wondering if there has been done a patch for NTPClient.h

Additional context

Additional reports

@MHotchin
Copy link

MHotchin commented Dec 7, 2019

I have seen this problem as well. This date seems to correspond to an NTP time of 0x0000000 in the seconds component. Once the code subtracts 70 years, the resulting Unix time corresponds to the date above.

@MHotchin
Copy link

MHotchin commented Dec 7, 2019

I decided to to add some error checking, since then I haven't seen the problem. I've forked and committed my changes here:
https://github.com/MHotchin/NTPClient

Summary:

  • more error checking around all UDP calls
  • move _packetBuffer from the class into the two functions where it is used. Saves 48 bytes!
  • (enhancement for my own use) - caller can provide an OPTIONAL function to 'forceUpdate', the code will call that instead of 'delay()' while it waits for a reply. I use it so my sketch doesn't block while NTP does its thing.

@debuggerEx
Copy link

debuggerEx commented Jan 19, 2020

Hi,

I have the same problem. Maybe like this gmag11/NtpClient#70

last version

Thanks!

@ZsZs73
Copy link

ZsZs73 commented Feb 8, 2022

I am pretty sure that we are facing with rate limiting of NTP servers here.
NTP response with time stamp in it
NTO_resp-OK
NTP RATE limit response
NTP_resp_RATE

A simple check on the received response would do the trick: ignore the response if Peer Clock Stratum=0 and Reference ID='RATE'

How to reproduce:

  1. set up a local NTP server
  2. append limited keyword to line restrict default kod nomodify notrap nopeer noquery in ntpd.conf
  3. restart ntpd

The default limited allows average 32s (2^5) between two requests from the same source IP and the minimum between two requests is 4s (2^2) seconds according to the ntp.conf manual

To trigger RATE limiting simply produce NTP requests exceeding the above limit.

Related issues:

@elgerg
Copy link

elgerg commented Jun 2, 2022

I kept getting this so set up a local NTP server but that hasnt made any difference.

Are we any closer to getting a fix in place?

@ZsZs73
Copy link

ZsZs73 commented Jun 3, 2022

Actually I found out that the DHCP server sends NTP server (option 42) address for IoT devices.
This was a leftover of some experiment as this setting works well with OpenWRT clients.

In this case NTPclient behavior is the following:

  • first contact the NTP server received via DHCP. As far as I remember this request is malformed, so the reply contains no time info.
  • second contact the NTP server set in the NTPclient config. In my case it was the same NTP server running on the router, but with rate limiting enabled. So again no time info received.

My fix is the following:

  • remove NTP server from DHCP configuration (at least for the IoT subnet)
  • disable RATE limiting on the NTP server (at least for the IoT subnet)
    I think that one of the above should fix the problem.

With the above settings all my IoT devices relying on NTPclient are working stable.

edit: i think that the original issue is that some sanity check of the NTP reply received is missing or insufficient.
My fix is just a workaround.

@Der-Schubi
Copy link

Could this please be fixed?
This is known for almost five years now...

@per1234 per1234 added type: imperfection Perceived defect in any part of project topic: code Related to content of the project itself labels Jun 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: code Related to content of the project itself type: imperfection Perceived defect in any part of project
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants