[PLUG] ntpd and subnet

Mike C. mconnors1 at gmail.com
Sun Jun 29 02:10:24 UTC 2014


> Message: 1
> Date: Tue, 24 Jun 2014 10:49:20 -0700 (PDT)
> From: Rich Shepard <rshepard at appl-ecosys.com>
> Subject: [PLUG] ntpd and subnet
> To: plug at pdxlinux.org
> Message-ID: <alpine.LNX.2.11.1406241036270.2555 at 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.



More information about the PLUG mailing list