Guys, I was afraid this might happen. There is no such port check in the development branch, so somebody broke my rules not to change ntp_proto.c withhout my permission. The result not only breaks the specification, it disables symmetric active/active modes. Any check like this has to be mode dependent, so whoever made the change eithher doesn't believe the specification or doesn't understand symmetric modes or both.
This is the main reason I object to changing the files I specifically reserve for my own paws, including ntp_proto.c, ntp_crypto.c, ntp_loopfilter.c and ntp-keygen.c, between development merges and I'm rather pissed off. Dave Ronan Flood wrote: > On Tue, 1 Apr 2008 12:44:17 -0400, "Ray" <[EMAIL PROTECTED]> wrote: > > >>input_handler: if=2 fd=6 length 48 from 453fdb02 69.63.219.2 >>receive: at 38 132.246.168.2<-69.63.219.2 restrict 00 > > >>receive: at 182 132.246.168.2<-69.156.105.192 restrict 00 >>receive: at 182 132.246.168.2<-69.156.105.192 mode 3 code 2 >> MCAST *****sendpkt(fd=6 dst=69.156.105.192, src=132.246.168.2, ttl=0, >>len=48) >>transmit: at 182 132.246.168.2->69.156.105.192 mode 4 > > > >>>Ray> I am running stratum-1 servers with NTP version 4.1.0. > > > Compare the above two client addresses in the output of > "ntpdc -nc monlist 132.246.168.2" : > > remote address port local address count m ver drop last first > > 69.63.219.2 353 132.246.168.2 99 3 3 0 18 6354 > > 69.156.105.192 2605 132.246.168.2 11 3 4 0 294 6309 > > > Then examine this piece of code in ntp-4.1.0/ntpd/ntp_proto.c receive() : > > if (!(SRCPORT(&rbufp->recv_srcadr) == NTP_PORT || > SRCPORT(&rbufp->recv_srcadr) >= IPPORT_RESERVED)) { > sys_badlength++; > return; /* invalid port */ > } > > QED. Time to upgrade to a later version ... > _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions