Unexpected origin timestamp ... does not match aorg 0000000000.0000

17 views
Skip to first unread message

Mabry T

unread,
Mar 4, 2022, 8:21:29 AMMar 4
to
I have a set of (local) NTP peers, and a host that is a client of them. (Ubuntu 18.04, with their ntp 4.2.8p10 derivative). It has been getting log messages of the form
ntpd[2779]: receive: Unexpected origin timestamp 0xe5c94914.1cfa0625 does not match aorg 0000000000.0000
0000 from sym_a...@A.B.C.D xmt 0xe5c94928.e8f5c510
where the sources (A.B.C.D) include the the servers for the client.

There were a number of hits on that log message when I searched the net, but none I saw seemed appropriate to me.

I captured the NTP packets from one server to the client over a period of about 10 log messages. In exactly those cases (on the order of half of the packets) where the log message was generated, the origin timestamp was the same as in the previous packet. AIUI, that means that the server had not gotten an update from its authority in the interval between the server's packets to the client.

It makes sense that NTP would disregard that packet. But it didn't - it generated a log message.

I noticed that one of my (Cisco-ntpv4-1.0) NTP servers reported
system poll interval is 1024, last update was 2269 sec ago.

That's starting to make sense. If the selected upstream server (external to me, and not pool.ntp.org) is taking longer to answer than expected, then my server will send out two or more packets that have the same origin time. This situation may be uncommon, which may explain why I didn't easily find such an explanation.

I'm not that familiar with the internals of NTP, so does this make sense? Is this log message a misfeature that should be reported to the maintainers, at least with a request to make the situation clearer to end users?

(As it turned out, those 3 peers were essentially using just two external servers. That wasn't the design, but other configured external servers were no longer accessible. That's been corrected. But this lack of external servers made for an incestuous situation that meant the log message happened more frequently.)

Derek Barnes

unread,
Mar 5, 2022, 7:23:04 PMMar 5
to
On Saturday, March 5, 2022 at 2:21:29 AM UTC+13, Mabry T wrote:

> That's starting to make sense. If the selected upstream server (external to me, and not pool.ntp.org) is taking longer to answer than expected, then my server will send out two or more packets that have the same origin time.

No, NTP runs on UDP so there should be not follow-up packets sent with the same timestamp. You are thinking of TCP.
Reply all
Reply to author
Forward
0 new messages