On Fri, Nov 1, 2013 at 10:09 AM, Gedare Bloom <ged...@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 <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
