Dave, In article <8c5b8d60-8780-4bf0-80da-6b1d19410...@k24g2000pro.googlegroups.com>, Dave Hart <daveh...@gmail.com> wrote:
> On Mar 17, 03:30 UTC, Joseph Gwinn wrote: > > Looking in section B.2.2 of RFC 1305 yields that the Peer Status Field has > > four > > subfields, the last (rightmost) one of which being the 4-bit Peer Event Code > > (page 57), which is defined for values between 0 and 5, and is "reserved" > > for values 6 to 15. > > > > Well, I have been seeing two values of Peer Status, 9614 and 963a, both > > hexidecimal. I understand 9614, but 963A is a mystery, as it implies a Peer > > Event Code of 10 (the "A" in the rightmost digit), which is undefined and > > reserved in RFC 1305. > > Scan for "PEVNT_" in ntp.h: > > <http://ntp.bkbits.net:8080/ntp-stable/include/ntp.h?PAGE=anno&REV=4af5f8cfDBBhNWjyJ4XiD74vlioxeg> > > #define PEVNT_MOBIL (1 | PEER_EVENT) /* mobilize */ > #define PEVNT_DEMOBIL (2 | PEER_EVENT) /* demobilize */ > #define PEVNT_UNREACH (3 | PEER_EVENT) /* unreachable */ > #define PEVNT_REACH (4 | PEER_EVENT) /* reachable */ > #define PEVNT_RESTART (5 | PEER_EVENT) /* restart */ > #define PEVNT_REPLY (6 | PEER_EVENT) /* no reply */ > #define PEVNT_RATE (7 | PEER_EVENT) /* rate exceeded */ > #define PEVNT_DENY (8 | PEER_EVENT) /* access denied */ > #define PEVNT_ARMED (9 | PEER_EVENT) /* leap armed */ > #define PEVNT_NEWPEER (10 | PEER_EVENT) /* sys peer */ > #define PEVNT_CLOCK (11 | PEER_EVENT) /* clock event */ > #define PEVNT_AUTH (12 | PEER_EVENT) /* bad auth */ > #define PEVNT_POPCORN (13 | PEER_EVENT) /* popcorn */ > #define PEVNT_XLEAVE (14 | PEER_EVENT) /* interleave mode */ > #define PEVNT_XERR (15 | PEER_EVENT) /* interleave error */ > #define PEVNT_TAI (16 | PEER_EVENT) /* TAI */ This almost answers the immediate question, but what exactly is a "sys peer" event? More generally, the comments on many event codes lack verbs, defeating the reader. Perhaps these codes are expanded in ntpq; I'll look ... > To match the literal text output by ntpd/ntpq when decoding, see also > libntp/statestr.c: > > <http://ntp.bkbits.net:8080/ntp-stable/libntp/statestr.c?PAGE=anno&REV=4ac6e036jH41_maMfVXyf2VeiFknzQ> ... by following this breadcrumb trail. > There may be an easier way, but looking at the source comes naturally > to me. There isn't an easier way for most people until the NTPv4 documentation is updated, which is essential. Right now, the NTPv4 documentation points users and sysadmins to an authoritative but incomplete answer. I knew that the answer had to be in the ~70,000 lines of NTP source code, but wouldn't really know which rock to look under. Very few people have the time to know this much source code well enough to find the correct answer, and to know that the found answer is in fact correct. Which is why the NTPv4 documentation needs to be revised to reflect the as-built NTPv4 code. NTP has many millions of users, but at most a few hundred developers (where a "developer" is someone who knows his way around the source code). Thanks, Joe
_______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
