NTP broadcast problems with RTEMS 4.10.2 and 4.11

Jim Panetta panetta at slac.stanford.edu
Wed Oct 30 00:40:11 UTC 2013


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!



More information about the devel mailing list