NTPClient object sets time to 2036-02-07

[jnew123]

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

• Add handling for NTP server returning 0 #193

[MHotchin]

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]

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]

Hi,

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

last version

Thanks!

[ZsZs73]

I am pretty sure that we are facing with rate limiting of NTP servers here.
NTP response with time stamp in it

NTP RATE limit response

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:

• sometime time server does not provide valid time , this need to be managed inside NTPClient::forceUpdate()  #133
• Incorrect date/year with ESP8266 board 3.0.0 #149
• Refuses to work with the NTP server sometimes #157
  From forks/other repos:
• NTP sync returns random day and time for the year 2036 gmag11/NtpClient#70
• Clock is set to 2036-02-07 about 7:30AM sometimes by sync ropg/ezTime#25
• NTPClient accepts malformed responses SmingHub/Sming#2040
• Clock is set to 2036-02-07 sometimes sstaub/NTP#9

[elgerg]

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]

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]

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