[ntp:hackers] What does "interface listen wildcard" do?

Danny Mayer mayer at ntp.org
Wed Jul 10 03:30:35 UTC 2013


On 7/9/2013 12:12 PM, Brian Utterback wrote:
> If you are not listening on the wildcard address, on what socket would
> you expect to receive a broadcast packet that was sent to 255.255.255.255?
> 

The short answer is "DON'T".

The longer answer is that such packets are not allowed to be forwarded
by a router so you should use a specific subnet specific address, e.g.
10.10.10.255 when using broadcast mode. I think that we allowed the
wildcard address for such packets but it's not good news and interferes
with configuring specific addresses.

Danny

> On 7/8/2013 5:00 PM, Danny Mayer wrote:
>> Listening on the wildcard address is not normally useful here. The
>> listen that was added for the wildcard was done because at least one O/S
>> was not getting packets on the NTP port but I don't remember which O/S
>> and which type of packet. You should not normally need the wildcard
>> socket for broadcast. I haven't looked at the code for some years but it
>> should be seeing and receiving broadcast packets if the right socket
>> info is set up for it.
>>
>> I know it used to work, I did plenty of debugging with broadcast packets.
>>
>> Danny
>>
>> On 7/6/2013 9:04 PM, Brian Utterback wrote:
>>> I never got any response to this last message. I am preparing to release
>>> a new version of NTP in the development version of Solaris, and I have
>>> customers that would really like to use the broadcast functionality.
>>> Does anyone have broadcast working (not multicast) and if so, what did
>>> you have to do? This seems like pretty basic functionality to be broken
>>> for so long.
>>>
>>> On 08/15/12 11:10, Brian Utterback wrote:
>>>> I removed the check for INT_WILDCARD, and that got it past
>>>> io_setbcast, but that still did not enable the broadcast client
>>>> functionality. According to the debug output the broadcast packets are
>>>> being received, but the code that tries to match them to an interface
>>>> fails.
>>>>
>>>> On 08/15/12 06:57, Brian Utterback wrote:
>>>>> I haven't tried that yet since I didn't understand the code here well
>>>>> enough to risk modifying it. I was thinking of setting a flag when
>>>>> "listen  wildcard" was given to accept wildcard only then.
>>>>>
>>>>>   On 08/15/12 00:04, Dave Hart wrote:
>>>>>> On Tue, Aug 14, 2012 at 5:52 PM, Brian Utterback
>>>>>> <brian.utterback at oracle.com>  wrote:
>>>>>>> I have a customer that want to get broadcastclient to work, but it
>>>>>>> does not
>>>>>>> because we ignore the wildcard interfaces by default. When I first
>>>>>>> asked
>>>>>>> about this some time ago, it was suggested that with a newer
>>>>>>> version of ntpd
>>>>>>> the customer could specify with the interface command to listen
>>>>>>> to the
>>>>>>> wildcard addresses.
>>>>>>>
>>>>>>> So, I am testing the latest version (2.6.7p294) to verify that this
>>>>>>> fixes
>>>>>>> the problem, but I am running into a problem. When I add this line
>>>>>>> to the
>>>>>>> ntp.conf file: "interface listen wildcard", I get this error:
>>>>>>>
>>>>>>> "Unable to listen for broadcasts, no broadcast interfaces available"
>>>>>>>
>>>>>>> This message comes from the function io_setbclient. The very first
>>>>>>> test in
>>>>>>> the processing loop inside io_setbclient has this test:
>>>>>>>
>>>>>>>                   if (interf->flags&  (INT_WILDCARD | INT_LOOPBACK))
>>>>>>>                           continue;
>>>>>>>
>>>>>>> As it happens, when it does this processing there are three
>>>>>>> interfaces on
>>>>>>> the list, the v4 wildcard, the v6 wildcard, and the lo0 loopback,
>>>>>>> all of
>>>>>>> which are rejected by this test.
>>>>>>>
>>>>>>> So, am I misunderstanding what this command is supposed to be
>>>>>>> doing, or is
>>>>>>> this a bug?
>>>>>> I suspect it's a bug.  Does your customer get any further along if
>>>>>> the
>>>>>> io_setbclient() code is modified to not reject wildcards?
>>>>>>
>>>>>> Cheers,
>>>>>> Dave Hart
>>>>>
>>>>
>>>
>>
> 
> 
> 



More information about the hackers mailing list