Refuses to work with the NTP server sometimes

[ghost]

This might be a longshot before I replace this library but hey maybe someone here have some clues.

I'm using the latest version of this library in various projects. This works reliably for even the long run with the first server not with the second. With the second it works sometimes then at 1 point it decides not to, even if I restart the ESP8266 many times.

Just don't get it why. From my laptop or from other workstations both NTP servers providing the correct date, also there are no firewalls. The working version is even an older one.

WORKING SERVER

ii ntp 1:4.2.6.p5+dfsg-2+deb7u7 amd64 Network Time Protocol daemon and utility programs

ntpdate -d 1.2.3.4
23 Nov 18:10:12 ntpdate[937]: ntpdate [email protected] Sun Feb 25 21:22:56 UTC 2018 (1)
transmit(1.2.3.4)
receive(1.2.3.4)
transmit(1.2.3.4)
receive(1.2.3.4)
transmit(1.2.3.4)
receive(1.2.3.4)
transmit(1.2.3.4)
receive(1.2.3.4)
server 1.2.3.4, port 123
stratum 2, precision -23, leap 00, trust 000
refid [1.2.3.4], delay 0.05536, dispersion 0.00018
transmitted 4, in filter 4
reference time:    e5479db3.59bf632e  Tue, Nov 23 2021 18:04:51.350
originate timestamp: e5479efa.89d517e5  Tue, Nov 23 2021 18:10:18.538
transmit timestamp:  e5479efa.86ca5636  Tue, Nov 23 2021 18:10:18.526
filter delay:  0.05574  0.05536  0.05550  0.05571 
         0.00000  0.00000  0.00000  0.00000 
filter offset: -0.00356 -0.00356 -0.00334 -0.00325
         0.000000 0.000000 0.000000 0.000000
delay 0.05536, dispersion 0.00018
offset -0.003561

23 Nov 18:10:18 ntpdate[937]: adjust time server 1.2.3.4 offset -0.003561 sec

BROKEN SERVER

ii ntp 1:4.2.8p10+dfsg-3+deb9u2 armhf Network Time Protocol daemon and utility programs

ntpdate -d 1.2.3.5
23 Nov 18:11:08 ntpdate[2079]: ntpdate [email protected] Sun Feb 25 21:22:56 UTC 2018 (1)
transmit(1.2.3.5)
receive(1.2.3.5)
transmit(1.2.3.5)
receive(1.2.3.5)
transmit(1.2.3.5)
receive(1.2.3.5)
transmit(1.2.3.5)
receive(1.2.3.5)
server 1.2.3.5, port 123
stratum 3, precision -20, leap 00, trust 000
refid [1.2.3.5], delay 0.02670, dispersion 0.00012
transmitted 4, in filter 4
reference time:    e5479a5b.b6d2279b  Tue, Nov 23 2021 17:50:35.714
originate timestamp: e5479f33.12da26e4  Tue, Nov 23 2021 18:11:15.073
transmit timestamp:  e5479f33.1433e734  Tue, Nov 23 2021 18:11:15.078
filter delay:  0.02676  0.02670  0.02708  0.02684 
         0.00000  0.00000  0.00000  0.00000 
filter offset: -0.00617 -0.00596 -0.00574 -0.00606
         0.000000 0.000000 0.000000 0.000000
delay 0.02670, dispersion 0.00012
offset -0.005969

23 Nov 18:11:15 ntpdate[2079]: adjust time server 1.2.3.5 offset -0.005969 sec

It is also not a network connection issue, the ESP8266 can connect to the wifi fine it just can't get the time from the NTP for some reason.

Any ideas how to proceed with this?

[ZsZs73]

IMHO the problem is that NTPClient sends two NTP requests right after each other and some servers have rate limit in place, like my OPNsense firewall by default. See the OPNsense issue In case you can run a tcpdump -A between the device running NTPClient and the NTP server (for example on your router or or a switch monitor port) then you'll see that the second reply contains the string RATE. This means that the server rejects the response. Long story short: ntpdate sends NTP requests with tolerable rate but NTPclient does not.

I think that this should be addressed on client level otherwise NTP servers in the pool get overloaded, especially with 60 secs update interval, which is very short.

edit: added explanation about RATE response from the NTP server edit2: typos edit3: added reference to the OPNsense issue