[ntp:questions] ntpd and network sockets

Danny Mayer mayer at ntp.isc.org
Thu Jan 10 00:29:04 UTC 2008


Rick Jones wrote:
> 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 :)
> 
It should say address and does indeed apply to both IPv4 (0.0.0.0) and 
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).
> 

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.

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

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.

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


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

No that's not the meaning of query-on. The addresses being bound are 
listed in the listen-on list. The query-on list just specifies which one 
to use for outgoing queries and those addresses must already exist and 
be bound or it won't find the address. You don't need the address family 
since the code already knows that from the address to which it wants to 
send the data so it's already self-limiting in the address family.

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

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

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

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

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.

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

Correct.

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

Yep. It also will pick up broadcast packets even if you don't specify 
them. This one caught us at one time when we were dropping packets from 
the wildcard socket and not freeing the memory. It doesn't take too long 
to run out of memory in such a case!

Danny

> rick jones




More information about the questions mailing list