Ntp Client

Rick Stevens rstevens at vitalstream.com
Thu Feb 19 19:17:52 UTC 2004


Bruce McDonald wrote:
> Hello Rick
> 
> On 19-Feb-04, you wrote:
> 
> 
>>Bruce McDonald wrote:
>>
>>>Hello,
> 
> 
>>>I appologise for the long post.
> 
> 
>>>I have just spent a "fun" day yesterday trying to get ntpd to sync my
>>>clock to a
>>>timeserver, and have failed.
> 
> 
>>>The only time it did work was when I started X, went to Main Menu Button
>>>=> System Settings => Date & Time and specified a timeserver there.
>>>Unfortunatly that only lets you use one server, I wanted to have several
>>>to keep my clock honest.
> 
> 
>>>A note to those who will suggest ntpdate and a cron job..... I really
>>>want to use ntpd as my clock gains ~20 seconds a day (rough estimate).
> 
> 
>>>I was unable to find any documentation that told me what to do properly.
>>>I think I figured out what to do with the ntp.conf file, but I don't see
>>>any traffic when I run tcpdump port ntp. Ntpq -p show my timeservers but
>>>none are marked.
> 
> 
>>>Ntpq -p:
>>>    remote refid st t when poll reach delay offset jitter
>>>
> 
> ==============================================================================
> 
>>>tick.usnogps.na 0.0.0.0         16 u    -   64    0    0.000    0.000
>>>4000.00
>>>timekeeper.isi. 0.0.0.0         16 u    -   64    0    0.000    0.000
>>>4000.00
>>>clock.redhat.co 0.0.0.0         16 u    -   64    0    0.000    0.000
>>>4000.00
>>>clock2.redhat.c 0.0.0.0         16 u    -   64    0    0.000    0.000
>>>4000.00
> 
> 
>>>This is what I have in my ntp.conf file:
>>>(Is there anything wrong here?)
> 
> 
>>># Prohibit general access to this service.
>>>restrict default ignore
> 
> 
>>># Permit all access over the loopback interface.  This could
>>># be tightened as well, but to do so would effect some of
>>># the administrative functions.
>>>restrict 127.0.0.1 
> 
> 
> 
>>># -- CLIENT NETWORK -------
>>># Permit systems on this network to synchronize with this
>>># time service.  Do not permit those systems to modify the
>>># configuration of this service.  Also, do not use those
>>># systems as peers for synchronization.
>>># restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap
> 
> 
> 
>>># --- OUR TIMESERVERS ----- 
>>># or remove the default restrict line 
>>># Permit time synchronization with our time source, but do not
>>># permit the source to query or modify the service on this system.
> 
> 
>>># restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap
>>>noquery
>>># server mytrustedtimeserverip
> 
> 
> 
> 
>>># --- NTP MULTICASTCLIENT ---
>>>#multicastclient            # listen on default 224.0.1.1
>>># restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap
>>># restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap
> 
> 
> 
> 
>>># --- GENERAL CONFIGURATION ---
>>>#
>>># Undisciplined Local Clock. This is a fake driver intended for backup
>>># and when no outside source of synchronized time is available. The
>>># default stratum is usually 3, but in this case we elect to use stratum
>>># 0. Since the server line does not have the prefer keyword, this driver
>>># is never used for synchronization, unless no other other
>>># synchronization source is available. In case the local host is
>>># controlled by some external source, such as an external oscillator or
>>># another protocol, the prefer keyword would cause the local host to
>>># disregard all other synchronization sources, unless the kernel
>>># modifications are in use and declare an unsynchronized condition.
>>>#
>>># server    127.127.1.0    # local clock
>>>server navobs1.usnogps.navy.mil 
>>>server timekeeper.isi.edu 
>>>server clock.redhat.com
>>>server clock2.redhat.com 
>>>server ntp1.linuxmedialabs.com 
> 
> 
>>>fudge   127.127.1.0 stratum 10
> 
> 
> 
>>>#
>>># Log file (added Feb 18, 2004)
>>>#
>>>logconfig    all
>>>logfile        /var/log/xntpd
> 
> 
>>>#
>>># Drift file.  Put this in a directory which the daemon can write to.
>>># No symbolic links allowed, either, since the daemon updates the file
>>># by creating a temporary in the same directory and then rename()'ing
>>># it to the file.
>>>#
>>>driftfile /etc/ntp/drift
>>>broadcastdelay    0.008
> 
> 
>>>#
>>># Authentication delay.  If you use, or plan to use someday, the
>>># authentication facility you should make the programs in the auth_stuff
>>># directory and figure out what this number should be on your machine.
>>>#
>>>authenticate yes
> 
> 
>>>#
>>># Keys file.  If you want to diddle your server at run time, make a
>>># keys file (mode 600 for sure) and define the key number to be
>>># used for making requests.
>>>#
>>># PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
>>># systems might be able to reset your clock at will. Note also that
>>># ntpd is started with a -A flag, disabling authentication, that
>>># will have to be removed as well.
>>>#
>>>keys        /etc/ntp/keys
> 
> 
> 
> 
>>>In case the firewall was blocking communication I added lines to allow
>>>ntp to pass.
> 
> 
>>>#Deny TCP and UDP packets to privileged ports
>>>$IPTABLES -A INPUT -i $EXTIF -p tcp --dport 123 -j ACCEPT
>>>$IPTABLES -A INPUT -i $EXTIF -p udp --dport 123 -j ACCEPT
>>>$IPTABLES -A INPUT -i $EXTIF -p udp --dport 0:1023 -j DROP
>>>$IPTABLES -A INPUT -i $EXTIF -p tcp --dport 0:1023 -j DROP
> 
> 
>>>Still no communication.  Can anyone shed any light on how to get ntpd to
>>>work properly as a client?
> 
> 
>>Ah, um, are you on a cable or DSL router and is its firewall configured
>>to allow incoming TCP/UDP port 123?  I don't see anything evil in
>>your ntp.conf or iptables.
> 
> 
> I am connected via a DSL modem with the linux box being the network router.

Ok, let's try something simple.  Try:

	tcpdump port 123

in one window, then stop and restart xntpd.  Verify that you actually
see traffic.  If not, you might try turning off iptables and trying
again.  If it works the second time, look higher up in your iptables
to see if you have a block before your "--dport 123 -j ACCEPT" lines.
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-     "Daddy, why doesn't this magnet pick up this floppy disk?"     -
----------------------------------------------------------------------





More information about the Redhat-install-list mailing list