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.
-Gedare On Fri, Nov 1, 2013 at 10:01 AM, Gedare Bloom <ged...@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 <pane...@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 >>> >>> pane...@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 pane...@slac.stanford.edu >> >> -- >> My opinions are mine...not DOE's...not SLAC's...mine. >> (except by random, unforseeable coincidences) >> pane...@slac.stanford.edu -- Save the whales! Free the mallocs! >> _______________________________________________ >> rtems-devel mailing list >> rtems-devel@rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-devel _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
