NTP broadcast problems with RTEMS 4.10.2 and 4.11

[Gedare Bloom]

I generated a patch against the RTEMS head. Please double-check that
it works correctly (I did not try it out.) Hopefully Joel or someone
else knowledgeable about the networking stack / NTP will weigh in.
-Gedare

On Tue, Oct 29, 2013 at 8:40 PM, Jim Panetta <panetta at slac.stanford.edu> wrote:
> Hello,
>
> I've been having trouble with Network Time Protocol broadcasts under RTEMS
> 4.10.2 and 4.11 (HEAD).  Non-broadcast works perfectly fine.
>
> For non-broadcast, my RTEMS host is configured with the address of the NTP
> server, and my NTP server is configured with:
>
> restrict 172.21.7.192 mask 255.255.255.192 nomodify notrap nopeer
>
> With this, I see the request/reply packets after the call to
> rtems_bsdnet_synchronize_ntp(0,0) and the time is synced correctly.
>
>
> For an NTP server setup as broadcast, the situation is different.  With the
> server configuration line:
>
> broadcast 172.21.7.255 minpoll 4
>
> replacing the 'restrict' statement above and no server configured on the
> RTEMS
> host, I don't get sync.  I do see the UDP packets on the RTEMS host every 16
> seconds, but the time is not adjusted on receipt.
>
> Tracing this down found a couple of things that needed changing:
>
> 1) the value of rtems_bsdnet_ntpserver_count is equal to 0 when no
>    server is set, so the check for (rtems_bsdnet_ntpserver_count < 0)
>    in rtems_bsdnet_get_ntp() is wrong.  The check should be "<= 0".
>
> 2) Binding the listening socket port to 0 does not work.  Packets
>    appear on the interface, but the recvfrom in tryServer() never
>    returns.  Changing this to the well known NTP socket 123 allows the
>    packets to be seen. (See NOTE below)
>
> 3) In tryServer(), an explicit check for NTP version 3 packets is made.
>    If the NTP server is version 4, this check fails even though the
>    packets seem to be the right shape.
>
> NOTE: Change 2 conflicts with the changes made to rtems_bsd_net.c by Eric
> Norum and Joel Sherril between 2008-09-23 and 2008-09-26.  I could not find
> any mailing list traffic on this, other than one message from Daron Chabot
> on
> 2008-11-12 in reference to RTEMS 4.9.1:
> http://www.rtems.org/pipermail/rtems-users/2008-November/004455.html.
>
> With these changes both broadcast and non-broadcast seem to set the time
> correctly.  The only caveat is that for the broadcast mode,
> rtems_bsdnet_get_ntp() blocks until it gets a packet (or until timeout after
> 5*80 seconds).
>
>
> Here is the full patch I have made to our local installation:
>
> bash-3.2$ diff rtems_bsdnet_ntp.c rtems_bsdnet_ntp.c.orig
> 143a144,146
>>
>>       /* Changed ntp packet version match from '3' to '3 or 4', since
>
> version 4 will still work
>>
>>                panetta at slac.stanford.edu 2013-02-22
>>        */
>
> 145c148,149
> <               ((packet.li_vn_mode & (0x7 << 3)) == (3 << 3)) &&
> ---
>>
>>               (((packet.li_vn_mode & (0x7 << 3)) == (3 << 3)) ||
>>                ((packet.li_vn_mode & (0x7 << 3)) == (4 << 3))) &&
>
> 179c183
> <       myAddr.sin_port = htons (0);
> ---
>>
>>       myAddr.sin_port = htons (123);
>
> 195c199
> <               if (rtems_bsdnet_ntpserver_count < 0) {
> ---
>>
>>               if (rtems_bsdnet_ntpserver_count <= 0) {
>
>
>
> Prior to this being committed, Joel and/or Eric should probably weigh in.
>
>
> Thanks,
>
>   --Jim Panetta  panetta at slac.stanford.edu
>
> --
> My opinions are mine...not DOE's...not SLAC's...mine.
> (except by random, unforseeable coincidences)
> panetta at slac.stanford.edu  --  Save the whales!  Free the mallocs!
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel