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
