Harlan Stenn <[EMAIL PROTECTED]> 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... _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
