NTP broadcast problems with RTEMS 4.10.2 and 4.11

[Gedare Bloom]

On Fri, Nov 1, 2013 at 10:09 AM, Gedare Bloom <gedare at rtems.org> wrote:
> Also, these seem like bug fixes to me. It might be worth opening a PR
> on bugzilla [1] so we can track fixes back to 4.10.
>
Oops, forgot the link [1] https://www.rtems.org/bugzilla/

> -Gedare
>
> On Fri, Nov 1, 2013 at 10:01 AM, Gedare Bloom <gedare at rtems.org> wrote:
>> 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