TomatoUSB

I got this error in my router:

The following NTP servers have been automatically blocked by request from the server: xx.xx.xx.xx

What's with this error?

Running latest version. This also manifested in the previous version…

It means that the server gave you the the kiss of death. Use different servers.

http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse

NTP Time Servers may request that Tomato block them from being used in the future. If this happens, Tomato will display the following message: "The following NTP servers have been automatically blocked by request from the server: XXX.XXX.XXX.XXX."

This happens when Tomato encounters an ntp server which is out of synch with the master clocks. A stratum 0 clock would be a "master" and another server that takes its time from it would be "stratum 1". A server that takes it's time from that one would be "stratum 2". And so on.

Stratum 16 is reserved for servers that are not synchronized. That server advises clients trying to get accurate time that it cannot be relied upon as an accurate source as it is out of synch.

If you want Tomato to use that time source anyway, do

nvram set ntpc_kiss_ignore=1

I saw this back in June 2011, and just notoced it again today. I don't closely monitor the logs from Tomato, so I've probably missed other occurrences.

Thee is a thread on the topic here:
http://www.linksysinfo.org/index.php?threads/how-stop-automatic-blocking-of-ntp-servers.24438/

which I visited back in 2011, and set the nvram variable, but apparently it didn't resolve the issue.

ray123 wrote:

Use different servers.

I'm syncing to a LAN server. There is no reason why it should be rejecting the router's request. The ntpd logs show no records of the router being blocked.

The thread above speculates that the problem occurs when Tomato starts up at the same time as the NTP server, and the NTP server reports a stratum that Tomato's clent deems unsatisfactory, so the rejection is happening on the Tomato side.

It would seem the error message is possibly misleading, and there is likely a bug in the logic used to mark a server as having rejected the router.