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