"Interesting" changes - please test and keep an eye out for quirks

Eric S. Raymond esr at thyrsus.com
Tue Mar 20 09:31:51 UTC 2018


Hal Murray via devel <devel at ntpsec.org>:
> 
> I cleaned up the processing of received packets.  This has been on my list 
> for a while.  I finally looked at it right and it was simple.
> 
> There used to be a big table indexed by packet mode and peer mode.  That 
> handled multicast, responses to pool probes, and "peer" requests/responses.  
> We don't support multicast or peer mode, and the DNS lookup for the pool 
> creates the peer block before it sends the first packet so the pool response 
> now looks like a normal response from a server.
> 
> I also moved the parsed_pkt copy of a packet into the recvbuff to avoid a 
> calloc/free with each packet.
> 
> It all works in my setup, but I won't be surprised if there is some obscure 
> case that I don't test.

Good work.

You might soon get to do that cleanup of the network I/O you wanted to a while
back. Last time it was blocked because removing that grotty socket-per-interface
loop wasn't compatible with keeping the ability to filter by interface name.

However...I was revisiting that problem recently recently and found
some indications that it *is* possible to get the transit interface of
a recieved packet under Linux using CMSG.

If I can nail this down, and establish that there are equivalent capabilities
on all our primary target platforms, I may be able to write a packet_iface.c
parallel to packet_stamp.c.

And if that's true, most of ntp_io.c can turn into a single select on
a socket list.

Practical motivation: Daniel wants this for NTS support.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.




More information about the devel mailing list