[ntp:questions] ntpd and network sockets

Rick Jones rick.jones2 at hp.com
Thu Jan 10 01:24:13 UTC 2008

> The -L option only looks for colons (:) in the interface name and is not 
> a general method of dealing with "logical" interfaces. We really need to 
> get rid of it, which is what the listen-on code will do for people.

Speaking of colons, it is unfortunate that both (logical) interface
names, and IPv6 addresses have colons in them.  Thankfully I suppose,
an IPv6 address will always have at least two colons and presumably an
interface name will only have the one.  That way listen-on will be
able to distinguish an interface name from an IPv6 address even if it
cannot a priori distinguish between an interface and a DNS name.

> > In Security Issues, open-read-drop, it might be good to explicitly
> > mention SO_REUSEADDR and/or SO_REUSEPORT and how they may or may not
> > apply.
> > 

> SO_REUSADDR and/or SO_REUSEPORT are only useful if the address/port is 
> bound to a socket. SO_REUSADDR is used in the current code.

SO_REUSEPORT is the one that allows another process to bind to the
same port right?

> > Is there really much point in actually recving datagrams on such
> > sockets?  Could just as easily set the SO_RCVBUF to something "really
> > small" and then blythly ignore the socket entirely.  Yes, it means
> > that the stacks "socket buffer overflow" stat will increase I
> > suppose...
> > 

> The packets usually are small. 48 is the natural number of an NTP
> packet and only gets to be large if there are extension headers, for
> instance for autokey. The code only reads as much data as fits in
> the buffer and then ignores the contents so you cannot really get a
> buffer overflow.

I suspect we are thinking of different buffers.  I was talking about
the socket buffer - aka SO_RCVBUF - overflowing if ntpd simply bound a
socket and never read from it.  I wasn't thinking about a buffer
overflow in the ntpd itself.  Just trying to see if ntpd could avoid
even doing the partial read of the datagram(s) on the socket.

> > WRT query-on, last query-on wins.  Otherwise you have to extend to
> > rules to select which query-on when...
> > 

> I didn't understand that.

That's ok I might not have also :) If there were multiple query-on
statements and if more than one was to be "kept" as it were, then one
has to decide when to query from which.

> > WRT listen-on, "*" wouldn't specify address family.  If instead it
> > parsed 0 or for IPv4 wildcard, or text "INADDR_ANY" or ::0 for
> > IPv6 wildcard or whatever its macro is then it would be implicit.  I
> > don't think you can take both interface names and DNS names as
> > arguments because it will not be possible to distinguish one from the
> > other.  You could prioritize one over the other - a strawman would be
> > to match the string against interface names first before calling
> > getaddrinfo().  
> > 

> I am aware of no application that uses DNS to store its own list of 
> addresses and makes no sense to me.

I wasn't suggesting to use DNS to store things, just discussing issues
if one wanted to be able to take both interface names and DNS names as
arguments to something like listen-on.

> > If there is listen-on that means process and drop-on that means
> > readdrop (or opensock and no read) then ntpd doesn't have to care about
> > finding any other IP's on the system, they would be implictly
> > "ignored"  Thus IIRC there would no longer be any need/call for ntpd to
> > know how to enumerate all the IP's on a system and/or check that
> > periodically.  
> > 

> You do need to know in order for Autokey to work properly.


> > Unless, of course, the wildcard IP meant that it should open a socket
> > for each IP it finds rather than simply opening one socket bound to
> > the wildcard address.

> We cannot do that since we need to know the IP address being used and to 
> make sure we return packets with the same address. wildcard IP doesn't 
> give you that control.

In theory, if one wanted to have a socket for every IP on the system,
receipt of a message on the socket bound to the wildcard(s) could be
used as the trigger to say "time to scan the system for IP addresses"
You could then simply discard that message and rely on the remote to
send another.

Of course there is still a chance that some other process could get in
there and bind to the newly-added IP before a request arrived, and a
request to that IP will go to the closest match and so not the
wildcard-bound socket. Alas, there really is no (portable) way to be
completely assured that ntpd and only ntpd will receive traffic for
port 123 on all IPs on the local host.

> > FWIW I'd go with last wins, and process the config file as the command
> > line is processed.  Then, any command-line args after a config file
> > arg can override the config file, and the config file can override a
> > previous command-line.  But then I'm probably not writing the code,
> > just tossing things in from the peanut gallery.
> > 
> I am troubled by that too.

I didn't mean to imply I was troubled, just pointing-out how it might
conceivably work if one went with last-wins.

> > One thing about a socket bound to a wildcard address is that it will
> > pick-up traffic from interfaces enabled after ntpd has been started,
> > without ntpd having to periodically scan for new IP's on the system
> > (and possibly miss one that was only around for less than ntpd's
> > rescan interval).

I was wrong when I first said this - there will still be a window
where a new IP can be brought-up on the system, and some other process
can bind port 123 to that IP before ntpd can get there or traffic to
arrive.  Even if ntpd has a socket bound to the wildcard IP.

rick jones
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

More information about the questions mailing list