NTP Limited Broadcast - NTP

This is a discussion on NTP Limited Broadcast - NTP ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: NTP Limited Broadcast

  1. NTP Limited Broadcast

    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@kdcasey.net
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: NTP Limited Broadcast

    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@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@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  3. Re: 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@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@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


  4. Re: NTP Limited Broadcast

    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:
    Newsgroups: comp.protocols.time.ntp
    To:
    Sent: Tuesday, March 13, 2007 9:47 AM
    Subject: Re: 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@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@lists.ntp.isc.org
    >> https://lists.ntp.isc.org/mailman/listinfo/questions
    >>

    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  5. Re: NTP Limited Broadcast

    Kevin D. Casey wrote:
    > 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


    This whole issue bothers me. I'm hoping to be able to discuss it with
    some people next week when IETF is over and people are back.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


+ Reply to Thread