> Message: 1 > Date: Tue, 24 Jun 2014 10:49:20 -0700 (PDT) > From: Rich Shepard <[email protected]> > Subject: [PLUG] ntpd and subnet > To: [email protected] > Message-ID: <alpine.LNX.2.11.1406241036270.2555@localhost> > Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > > The ethernet-connected hosts here have static IP addresses. The wireless > access point serves dynamic IP addresses on a different subnet. Only two > portables use the WAP and both have a time keeping issue: each machine > gains > time and can get days ahead. > > I've set up one of the laptops to use na.pool ntp servers but it still > keeps gaining time. My Web searches and thread on linuxquestions.org have > produced no solution for the one laptop; just this morning I saw the second > has the same problem and realized the common factor is wireless > connectivity. > > Any ideas of why only the portables connecting via the WAP keep gaining > time would be much appreciated. Also, any diagnostics or tests I can run to > isolate the source of the problem would be good. > > TIA, > > Rich >
Rich, your best tools here are going to be logging and using the ntp commands to get some information back from the ntp daemon. The first thing I'd do is setup logging. If NTP is failing to startup your log file should be littered with error messages. Create an empty log file with: "touch /var/log/ntp.log" and then enter the line "logfile /var/log/ntp.log" into your ntp.conf and restart ntpd. What is the output of the command "ntpq -p and ntpq -n right after boot up? To the best of my knowledge, NTP is not a try once, fail and never try again. However, I do know they it will only try DNS resolution of the NTP servers once. So you can also try entering the ip addresses of your chosen NTP servers into ntp.conf to see if that's what is happening. My debian based laptop connects to internet ntp servers over wireless and is often suspended or off for days with no clock drift problems like you're experiencing. However, you can add these lines to your ntp.conf to server 127.127.1.0 fudge 127.127.1.0 stratum 10 "The fudge 127.127.1.10 stratum 10 directive is a “dummy” server acting as fallback IP in case the external time source becomes momentarily unreachable. When this happens, NTP will continue to work and base itself on this “internal” server." Good luck and I hope some of this is helpful to you. _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
