NTPClient accepts malformed responses

[fooker]

It looks like NTPClient is accepting malformed packages. Sometimes we receive NTP responses which are interpreted as 2036-02-07T06:28:16Z (which is the uint32 NTP rollover date).

It looks like the the received packet contains a all-zero timestamp which is processed as a valid packet. I've tried to capture these invalid packets on the used gateway but failed to do so - therefore I'm not sure if it's either a bogus response, an unsupported protocol version, an transition error on the WiFi or an firmware bug. Nevertheless, other libraries have seen these problems, too. They just add a check for timestamp == 0 to circumvent this (see gmag11/NtpClient#77).

Do you think adding such a check is the right way to fix this, or is it worth investigating whats the cause for this malformed packets?

[mikee47]

This comments suggests that zero timestamps are a legitimate response gmag11/NtpClient#70 (comment).

I just found the following in RFC 958 / Network Time Protocol:

In some cases a particular timestamp may not be available, such as
when the protocol first starts up. In these cases the 64-bit field
is set to zero, indicating the value is invalid or undefined.

So I'd say that even if you do get a response, a 0-timestamp can occur and needs to be handled.

[fooker]

@mikee47 I think so, too. I will come up with a PR after some testing.