[ntp:hackers] What does "interface listen wildcard" do?
philipp_subx at redfish-solutions.com
Fri Jul 12 19:51:21 UTC 2013
On Jul 12, 2013, at 5:59 AM, Danny Mayer <mayer at ntp.org> wrote:
> On 7/12/2013 10:33 AM, Brian Utterback wrote:
>> On 07/12/13 09:40, Danny Mayer wrote:
>>> If IP_PKTINFO was generally available on all O/S's with all of the
>>> information we needed it would have made some things easier but with the
>>> resulting problem of how to deal with incoming packets sent to an
>>> address that the admin didn't want to have people using.
>> The same way we do now, drop it. Remember that we do bind and receive
>> packets on the wildcard address, we just drop them.
> It's not as simple as that. Admins want to make sure that NTP clients
> don't try that address for NTP packets. They actually want it to return
> "refused" so that those clients don't try. Accepting and dropping
> packets means that something is accepting the packets. Dropping them is
> not the same thing at all.
"Refused" is a fungible notion on a connectionless protocol like UDP.
You can silently "drop" the packet, or you can send an ICMP Port-unreachable message back to the sender, but since it's an unacknowledged protocol, the kernel will return a SUCCESS status back to the API caller before the packet has a chance to reach its destination, much less have an ICMP come back.
>> Look, I think that the time has come to do some re-examination of some
>> of the design choices and to decide what the minimum requirements for
>> support are and look at doing some re-factoring based on those
>> decisions. Maybe we could take a modular approach and hide a lot of the
>> implementation details behind an abstraction layer, possibly turn some
>> of the design choices plugins.
> Yes. I'd like to break ntp_io.c apart again and put different pieces in
> different files.
>> We have had this same conversation nine years ago and then again five
>> years ago. If getting broadcast working again is doable, great. If not,
>> I can live with that. If we want to come out with an official "broadcast
>> is deprecated, use multicast" document, even better. But how about we
>> get down to it, define the minimum requirements and get cracking? We
>> keep speculating on whether this or that feature is supported on this or
>> that platform, but we don't really know, do we?
> Yes. Hopefully that can be considered for the next major release.
More information about the hackers