[ntp:questions] NTP Limited Broadcast

Kevin D. Casey kevin at kdcasey.net
Mon Mar 19 19:47:22 UTC 2007


I found the solution to this problem. NTP (at least on FreeBSD) does not 
broadcast on interfaces not associated with a broadcast command in ntp.conf. 
So in order to broadcast on 255.255.255.255 at least one network interface 
must be associated with a network that has the broadcast address 
255.255.255.255. In my case I accomplished this by installing a 2nd NIC and 
configuring it with the address 240.0.0.120/4. This class E network address 
has as it's broadcast address 255.255.255.255 and so NTP is able to 
broadcast on it. I'm not sure if this is THE ONLY solution, but it worked 
for me.

-Kevin

----- Original Message ----- 
From: <mills at udel.edu>
Newsgroups: comp.protocols.time.ntp
To: <questions at lists.ntp.isc.org>
Sent: Tuesday, March 13, 2007 9:47 AM
Subject: Re: [ntp:questions] NTP Limited Broadcast


> Danny,
>
> You scratch an old wound. When I wrote the first RFC on internet
> subnetting the conventional interpretation of 255.255.255.255 was
> broadcast to the world without limit. I though this a dumb idea and
> intended that broadcasts never went beyond the first-hop gateway.
>
> In review, my document did not say that explicitly; however, Bob Braden,
> who wrote the sequel, did strongly discourage propagation of broadcasts
> beyond the first-hop gateway. Therefore, the considered engineering
> judgement would be that anything other than the subnet bits at the left
> end of the address and other than the one bits at the right end be
> discarded forthwith. If the vendor in question does not understand that,
> switch to a different vendor.
>
> Once upon a time a favorite bogon was a packet with all ones in the
> destination AND source addresses, preferably in an ICMP echo request
> packet. Then measure the Ethernet temperature as result. I named such as
> Chernobyl packets and the result as broadcast storms. Gateways had what
> came to be known as Martian filters that grounded packets with bogus
> source and/or destination addresses. I assume modern gateways have
> equivalent defenses.
>
> Dave
>
> Danny Mayer wrote:
>> Kevin D. Casey wrote:
>>
>>>I am running NTP 4.2.2 on FreeBSD 6.2 broadcasting to clients on the
>>>broadcast address of an internal subnet 192.168.144.0/24 which is
>>>192.168.144.255. The server is using 192.168.144.120 on its network
>>>interface. The attached switch hardware on the subnet is able to
>>>receive the broadcasts and update its clock as an SNTP client. I have
>>>also verified the presence of UDP 123 broadcasts using Ethereal. I
>>>have a proprietary time recording device also attached to the same
>>>broadcast domain that appears to be unable to receive it's updates in
>>>this way. Although it is designed to listen for UDP 123 broadcast
>>>traffic, the manufacturer is claiming that it will only listen for
>>>broadcasts sent to 255.255.255.255. However when I try to reconfigure
>>>NTPD to use 255.255.255.255 instead of 192.168.144.255 the broadcast
>>>stops working. Can anyone tell me how to configure NTPD to broadcast
>>>on 255.255.255.255? -- Kevin D. Casey kevin at kdcasey.net
>>
>>
>> See Bug #779 https://ntp.isc.org/bugs/show_bug.cgi?id=779
>>
>> This has become a difficult issue to resolve. Although a socket gets set
>> up to accept broadcast packets packets sent to 255.255.255.255 only get
>> delivered to the wildcard socket where all packets get dropped. I'm not
>> sure why this is but it looks like all O/S's seem to ignore the
>> configured socket for this case in favor of the wildcard socket. I'm
>> trying to research this issue.
>>
>> Danny
>> _______________________________________________
>> questions mailing list
>> questions at lists.ntp.isc.org
>> https://lists.ntp.isc.org/mailman/listinfo/questions
>>
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 




More information about the questions mailing list