[Bug 2150] New: NTP Broadcast problems

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=2150

             Bug #: 2150
           Summary: NTP Broadcast problems
    Classification: Unclassified
           Product: RTEMS
           Version: 4.10
          Platform: All
               URL: http://www.rtems.org/pipermail/rtems-devel/2013-Octobe
                    r/004814.html
        OS/Version: RTEMS
            Status: NEW
          Severity: normal
          Priority: P3
         Component: cpukit
        AssignedTo: joel.sherrill at oarcorp.com
        ReportedBy: panetta at slac.stanford.edu


This issue was originally reported on rtems-devel at the linked URL.

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).

Gedare generated a patch from my original message:
http://www.rtems.org/pipermail/rtems-devel/2013-November/004877.html

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.