NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p10 was released on 21 March 2017 and addresses 6 medium- and 5 low-severity security issues, 4 informational security topics, 15 bugfixes, and contains other improvements over 4.2.8p9.

Please see the NTP Security Notice for vulnerability and mitigation details.

Bug 452 - kernel flipping between PLL and FLL
: kernel flipping between PLL and FLL
Status: VERIFIED FIXED
Product: ntp
Classification: Unclassified
Component: ntpd
: 4.2.0
: PC FreeBSD
: P3 normal
: 4.2.4
Assigned To: Harlan Stenn
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-06-15 12:42 UTC by Andriy Gapon
Modified: 2009-10-15 15:57 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andriy Gapon 2005-06-15 12:42:28 UTC
I've recently upgraded my FreeBSD from 5.2.1 to 5.3 and that also meant
that my ntp software version changed from 4.1.1b to 4.2.0.
After that I've started to get a lot of messages like:

Mar 30 23:18:01 oddity ntpd[400]: kernel time sync enabled 6001
Mar 30 23:19:13 oddity ntpd[400]: kernel time sync enabled 2001
Mar 31 08:36:16 oddity ntpd[400]: kernel time sync enabled 6001
Mar 31 08:53:20 oddity ntpd[400]: kernel time sync enabled 2001
Mar 31 11:44:02 oddity ntpd[400]: kernel time sync enabled 6001
Mar 31 12:18:08 oddity ntpd[400]: kernel time sync enabled 2001
Mar 31 13:26:30 oddity ntpd[400]: kernel time sync enabled 6001
Mar 31 13:43:35 oddity ntpd[400]: kernel time sync enabled 2001
Mar 31 17:32:07 oddity ntpd[400]: kernel time sync enabled 6001
Mar 31 17:49:11 oddity ntpd[400]: kernel time sync enabled 2001
Mar 31 20:22:54 oddity ntpd[400]: kernel time sync enabled 6001
Mar 31 20:39:59 oddity ntpd[400]: kernel time sync enabled 2001
Mar 31 21:14:08 oddity ntpd[400]: kernel time sync enabled 6001
Mar 31 21:31:11 oddity ntpd[400]: kernel time sync enabled 2001
Mar 31 22:39:28 oddity ntpd[400]: kernel time sync enabled 6001
Mar 31 22:56:31 oddity ntpd[400]: kernel time sync enabled 2001

As I understand these 2001<->6001 flips are kernel PLL<->FLL flips.

Please note that I do not use any tinker-ing nor change maxpoll/minpoll parameters.

Several other freebsd users have also reported the same problem on
freebsd lists and joint investigation showed that the most likely cause
is that ntp_adjtime(MOD_OFFSET) is not being called for longer than 2048
seconds (a parameter hardcoded in FreeBSD kernel). There was no
significant changes in this area of FreeBSD kernel between the releases.

Please also see
http://www.mail-archive.com/freebsd-stable@freebsd.org/msg67325.html
for some of the mentioned discussion on freebsd list(s).

The problem also remained after upgrade to FreeBSD 5.4.
ntpd version is not changed:
ntpd 4.2.0-a
Comment 1 Harlan Stenn 2006-12-20 22:21:52 UTC
(Dave,  I've added you as a Cc: on this bug - it is about whatever changed a
while ago that causes lines like this:

Mar 31 22:39:28 oddity ntpd[400]: kernel time sync enabled 6001
Mar 31 22:56:31 oddity ntpd[400]: kernel time sync enabled 2001

to be printed a lot).

I see 2 issues here:

- are the PLL/FLL flips happening "too often"

- is there a good reason these changes are being logged at LOG_NOTICE
instead of, say, LOG_INFO at lines 655 and 662 of the latest ntp_loopfilter.c

The behavior has changed from 4.2.0 to the present codebase, but I'm not sure
if we could or should do more.
Comment 2 David L. Mills 2006-12-21 00:52:36 UTC
Subject: kernel flipping between PLL and FLL

Harlan,

Applications that expect to use update intervals above 1024 s should not 
use the kernel. There is benefit only if a TCXO or OCXO is in use. On 
the other hand, when the STA_NANO flips is not significant and causes no 
loss in performance and the change in loop discipline is seamless. I 
have modified the code not to report that event.

Dave

bugzilla@ntp.isc.org wrote:

[---=| TOFU protection by t-prot: 33 lines snipped |=---]



-- 
 <mills@udel.edu>
Comment 3 Harlan Stenn 2006-12-27 06:59:05 UTC
Andriy,

I've applied Dave's patch to the codebase, which should fix the problem.

Please check the next tarball release and mark this bug as VERIFIED or
REOPENED, as appropriate.
Comment 4 Miroslav Lichvar 2007-01-07 13:39:05 UTC
With this patch I'm getting on linux these messages:

Jan  7 04:24:34 localhost ntpd[22578]: kernel time sync error 0001
Jan  7 05:32:52 localhost ntpd[22578]: kernel time sync error 0001
Jan  7 06:24:08 localhost ntpd[22578]: kernel time sync error 0001
Jan  7 07:15:23 localhost ntpd[22578]: kernel time sync error 0001
Jan  7 07:49:35 localhost ntpd[22578]: kernel time sync error 0001
Jan  7 08:40:51 localhost ntpd[22578]: kernel time sync error 0001
Jan  7 09:32:06 localhost ntpd[22578]: kernel time sync error 0001
Jan  7 10:40:25 localhost ntpd[22578]: kernel time sync error 0001
Jan  7 11:14:33 localhost ntpd[22578]: kernel time sync error 0001
Jan  7 11:48:44 localhost ntpd[22578]: kernel time sync error 0001
Jan  7 12:22:52 localhost ntpd[22578]: kernel time sync error 0001
Jan  7 12:56:59 localhost ntpd[22578]: kernel time sync error 0001
Jan  7 13:48:12 localhost ntpd[22578]: kernel time sync error 0001
Jan  7 14:22:23 localhost ntpd[22578]: kernel time sync error 0001
Comment 5 Harlan Stenn 2007-01-07 19:17:01 UTC
Miroslav,

That message happens when ntp_adjtime() returns an error condition.

Can you edit the line in ntp_loopfilter.c and add ": %m" to look like:

 "kernel time sync error %04x: %m"

and reply here?

Dave, are you OK with me adding the %m to the codebase?
Comment 6 Miroslav Lichvar 2007-01-08 11:22:22 UTC
Ok, but adjtimex() is returning 5 (not -1) in this case, probably not very
helpful:

Jan  8 11:28:19 localhost ntpd[18427]: kernel time sync error 0001: Resource
temporarily unavailable
Jan  8 12:02:29 localhost ntpd[18427]: kernel time sync error 0001: Success
Comment 7 David L. Mills 2007-01-08 14:48:20 UTC
Subject: kernel flipping between PLL and FLL

Harlan,

No, I am not. The message is explicitly conditioned on designated error 
bits, which do not appear in the error message. The operating system has 
broken the condition bits returned by the kernel syscall. Fix the 
operating system first. Do not change the returned semantics.

Dave

bugzilla@ntp.isc.org wrote:

[---=| TOFU protection by t-prot: 18 lines snipped |=---]



-- 
 <mills@udel.edu>
Comment 8 David L. Mills 2007-01-08 14:53:19 UTC
Subject: kernel flipping between PLL and FLL

I have no idea who sent this.

It is not a bug that the kernel flips between PLL and FLL mode. However, 
adjtimex() has nothing to do with the intended kernel or daemon design. 
It is, however, necessary to conform to the dynamics of the intended 
system design. Lose the adjtimex() and really believe the loop equations.

Dave

bugzilla@ntp.isc.org wrote:

[---=| TOFU protection by t-prot: 14 lines snipped |=---]



-- 
 <mills@udel.edu>
Comment 9 Steve Kostecke 2009-10-15 15:43:30 UTC
Please mark this bug as VERIFIED if you agree that it is fixed.

Or reopen it if further work is required.
Comment 10 David L. Mills 2009-10-15 22:10:49 UTC
Subject: kernel flipping between PLL and FLL

Steve,

The kernel is switching between PLL and FLL mode because the poll 
interval is changing. The behavior is notmal. but the irritating  
messages have been disabled in ntp-dev.

Dave

Steve Kostecke via the NTP Bugzilla wrote:

[---=| TOFU protection by t-prot: 12 lines snipped |=---]



-- 
David L. Mills <mills@udel.edu>