[ntp:questions] ntpd and network sockets

Rick Jones rick.jones2 at hp.com
Tue Jan 8 21:49:42 UTC 2008


Harlan Stenn <stenn at ntp.org> wrote:
> We're trying to nail down some better behavior for ntpd and network
> sockets.

> Please visit http://support.ntp.org/bin/view/Dev/NtpdAndNetworkSockets

In the legacy section, I presume where it says wildcard port it really
mean to say wildcard IP (INADDR_ANY)?  (And I presume at some point if
not already, its equivalent for IPv6 :)

The second paragraph of the legacy section - those interfaces with
colons in their names are IIRC "logical" interfaces and not virtual
interfaces (vlans).  In HP-UXspeak at least the two are different
(HP-UX could be added to that list along with Solaris and Linux).

Not sure what folks think a "large" number of sockets might be, but
unless it is in the three or four digits it isn't IMO large :)

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.

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...

WRT query-on, seems that a name/ip, and a desired address family -
AF_INET, AF_INET6 or AF_UNSPEC would be good.  Those are things one
would be passing to getaddrinfo() to flesh things out before calling
bind() on the socket.  If the source port isn't required to be 123
then add-in a port number.

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

WRT listen-on, "*" wouldn't specify address family.  If instead it
parsed 0 or 0.0.0.0 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().  

The other complication/opportunity from taking DNS names is the
getaddrinfo() call can return multiple IP's for a single name.
Strawman there is to listen-on all the IP's returned by getaddrinfo()
for a given name.

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.  

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.

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.


WRT "What about the wildcard socket" - in networking speak, there
isn't really a wildcard socket, there can be a socket bound to a
wildcard address :)

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).

rick jones
-- 
web2.0 n, the dot.com reunion tour...
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