NTP sync returns random day and time for the year 2036 #70
Comments
|
Yes, agreed, great library. I also am sometimes getting bogus dates in 2036. For example: I suspect there is an NTP server that is sending bad timestamps. Normal NTP will work okay because it will discard outliers. It is a problem here, because we do not cross-check or validate. I am looking to see if I can come up with a small/simple way to avoid this. |
|
Hello, Same problem here. But i can't figure when that appends. The bug was not present some time in past ... Anyway : NTP server set to ntp.local That's always the same date & time ... strange ! And => https://github.com/esp8266/Arduino/blob/master/tools/sdk/lwip/src/core/sntp.c Read this : /**
See ? 07/02/2036 06:28:16 (+1h for timezone) ? :) I think there is a problem of parsing sntp or an incompatibility between the esp sdk and the ntpclientlib ... What is your interpretation of this ? PS: i use a local NTP for debug purpose and i can assure you this is not a ntp server problem here. |
|
I have the same problem.. |
|
Yes it's 7:28 for me and it's pretty irritating |
|
I have it when WiFi coverase is poor |
|
I do have the same problem. Research shows that the time/date 07:28:16 07/02/2036 is the NTP roll-over date. The time stamp in NTP is given in seconds, starting from 1.1.1900 (UNIX starts 1.1.1970). If you start with 0xFFFFFFFF as an NTP time stamp and subtract the 70 years of offset in seconds, and then convert this to time/date you get 07-Feb-36 06:28:15 UTC. So the packet must have contained a time stamp of 0xFFFFFFFF or possibly 0. The library does not check for this at the moment (and it shouldn't have to). |
|
OK, I think this becomes clearer. I added a print statement for the NTP timestamp after decoding of the UDP packet. Here is the result: Looks like I do get a valid packet first. The second packet seems to be corrupt. And then the server isn't there anymore... |
|
I think I am starting to understand. There is a method called getTime. This method requests a NTP message from an NTP server and returns the new time. But if there is a timeout, it raises a noResponse ntpEvent and then it returns 0; This 0 then gets interpreted as 02/07/2036. I wonder, could this be fixed by always checking for noResponse?... |
|
I just found the following in RFC 958 / Network Time Protocol:
So I'd say that even if you do get a response, a 0-timestamp can occur and needs to be handled. |
|
I left a modified version of the example from the lib running, and it seems I wasn't quite right. Here it goes wrong: But here it doesn't: In the first example, the server sends a 0 timestamp and I get the year 2036 reading. In the second example, the server times out and the time remains intact. Perhaps it isn't that difficult to fix this thing after all. |
|
OK, I think I have a fix and I am currently testing it. It isn't easy, because I had no 0-timestamp over several hours. |
|
@TomsCircuits You might have easier time testing with dummy server returning bad timestamp. import socket, struct
server = socket.socket(AF_INET, SOCK_DGRAM)
server.bind(('0.0.0.0', 12345)) # runs server on all addresses and uses port 12345
while True:
data, addr = server.recvfrom(1024)
print(data) # this can be unpacked using struct.unpack
server.sendto(addr, data)Just needs changing default port NtpClient uses (or run as privileged user to use 123) About unpacking the data... edit: Also see https://tools.ietf.org/html/rfc5905#page-76
|
|
@TomsCircuits I have "better luck" with poor signal |
|
@mcspr And here is an example output showing received and transmitted data including errors (timestamp left zero in 3rd packet, no reply in 6th): On the client side I get something like this: |
|
So, I think there is an improvement. It is perhaps not perfect. One problem is that apparently each time things like timezone, etc. are changed, the lib starts an extra sync. And if that goes wrong, then the false data will actually be used. In most applications, I am guessing that this is no real issue. At least, in that case the sync interval goes back to short and so the wrong date will hopefully not be used for longer periods. A side effect is that if the timestamp is wrong during startup, the time is now set to 1/1/1970. |
|
Hi. I've had this project somehow stopped during a long time. Now, during some days I'm trying to evolve this lib to a more smart way to synchronize. I've included AsyncUDP version on develop branch. So, request is no more blocking while wainting for response. Please test it and check if there are any 2036 problem again. |
|
I was not able to compile with the development version. I confess to not testing with the example. My code was running with the release version. When I tested with the development version, I got: error: ambiguous overload for 'operator!=' (operand types are 'IPAddress' and 'int') f (ipaddr != NULL && ntpServerIPAddress != 0) What could I have done wrong? I installed ESPAsyncUDP-master to get this far. I am using LwIP vers 2 (low memory) could that be it? |
|
Please try latest version 3.0.0-beta |
|
As there are no further comments I close this issue. Feel free to reopen it if required. |
|
@lightning003 To the best of my knowledge the problem still exists, even in the betas. I don’t think that the root of the problem lies in the library. I think (based on no evidence whatsoever) that one sever in the pool is spitting out bad data. If you happen to get it, you experience the problem.
Here’s what I did:
NTP.begin();
Serial.println("starting time sync");
NTP.setTimeZone (TIMEZONE);
while ((year(now()) < 1980) || (year(now()) > 2035)) {
int i;
delay (500);
Serial.print("+");
i++;
if (i > 20) {
Serial.println(); Serial.print("..................... no NTP time!");
// you could reboot here if you wanted
}
}
Serial.println();
Serial.println(NTP.getTimeDateString())
The loop usually doesn’t go more than 3 iterations.
From: lightning003
Sent: Monday, November 4, 2019 4:28 AM
To: gmag11/NtpClient
Cc: bill-orange ; Comment
Subject: Re: [gmag11/NtpClient] NTP sync returns random day and time for the year 2036 (#70)
The issue is still there with 3.1.0, Also I don't see any specific commits fixing this issue. Anyone still stuck on this?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@bill-orange ... yes I am also not able to force reproduce the scenario [hence del the comment], it occurred for me with other libraries as well and seems like they have same/similar issue, guess I will sync two times or verify with other ntp server to be sure - I don't see any other way, |
|
So, after 7 years nothing has been done, I'm still getting 2036 most of the time from my SRM, even if the SRM UI show the correct time. |
Hello,
First of all... Great library!
I began using your library last week. Sometimes the NTP sync will return a date in the year 2036. Any thoughts as to why?
Best Regards,
Aaron
The text was updated successfully, but these errors were encountered: