One last release candidate (in name only) and a new -stable
Dave Hart
stable release, 4.2.6, and will soon see the first 4.2.7 -dev
release. If you look at the distribution points right now, there is a
ntp-4.2.6-RC.tar.gz. I expect within a day there will also be a
ntp-4.2.6.tar.gz, differing only in the version's -RC suffix (which is
replicated into quite a few files), as the final 4.2.6 version text
without -RC is now at the head of ntp-stable.
While I'm jumping the gun as the official 4.2.6 announcement and
tarball hasn't come, thanks to everyone who reported bugs, provided or
verified fixes, or otherwise help nudge NTP towards its first major
release in three years.
I have uploaded x86 Windows binaries for 4.2.6 to my website.
Regarding CVE-2009-3563 patched yesterday [1], versions of 4.2.4
through p7 are vulnerable, as are all versions of 4.2.5. The fix
first appears in 4.2.4p8 and 4.2.6. The crux of the bug was
responding to mode 7 responses with an error response. When triggered
between two ntpd servers, or in some cases with a single server
talking to itself, the ntpd processes would run away transmitting
packets and logging a message for each as fast as conditions
permitted, until something dropped a packet. When I first reproduced
it, syslog helpfully collapsed a quarter-million identical log lines
into one for me.
Cheers,
Dave Hart
[1] http://support.ntp.org/bin/view/Main/SecurityNotice#DoS_attack_from_certain_NTP_mode
Jan Ceuleers
> Regarding CVE-2009-3563 patched yesterday [1], versions of 4.2.4
> through p7 are vulnerable, as are all versions of 4.2.5. The fix
> first appears in 4.2.4p8 and 4.2.6. The crux of the bug was
> responding to mode 7 responses with an error response. When triggered
> between two ntpd servers, or in some cases with a single server
> talking to itself, the ntpd processes would run away transmitting
> packets and logging a message for each as fast as conditions
> permitted, until something dropped a packet. When I first reproduced
> it, syslog helpfully collapsed a quarter-million identical log lines
> into one for me.
>
> Cheers,
> Dave Hart
>
> [1] http://support.ntp.org/bin/view/Main/SecurityNotice#DoS_attack_from_certain_NTP_mode
Thanks to Robin and Dmitri for finding and reporting the problem!
David J Taylor
news:cb83daad-6ea3-43dd...@z4g2000prh.googlegroups.com...
[]
> I have uploaded x86 Windows binaries for 4.2.6 to my website.
> Cheers,
> Dave Hart
Thanks for that, Dave. Those binaries are running apparently correctly on
the five PCs where I've loaded them - Windows 2000 Server, Windows XP and
Windows-7 with GPS/PPS, Windows XP and Windows Vista with LAN sync.
Cheers,
David
G8KBV
tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid says...
Hi.
Can you confirm (or otherwise) the baudrate I need to set my GPS16LVC
to, to work correctly with Dave Hart's binaries on Windows? I know the
default NMEA rate is 4800 (I think) but I want to be sure on this, if
just to remove one variable for the next stage of my master plan. Once
I've found a "happy place" to site the GPS receiver itself.
Also, how do all the various binaries in the serialpps-yyyymmdd.zip
files work together, or have I missed a document download somewhere?
The patched NTPD binaries continue to work OK lan/wan synched at the
moment.
Cheers.
Dave Baxter.
David J Taylor
news:MPG.258dc4812...@news.demon.co.uk...
[]
> Hi.
>
> Can you confirm (or otherwise) the baudrate I need to set my GPS16LVC
> to, to work correctly with Dave Hart's binaries on Windows? I know the
> default NMEA rate is 4800 (I think) but I want to be sure on this, if
> just to remove one variable for the next stage of my master plan. Once
> I've found a "happy place" to site the GPS receiver itself.
>
> Also, how do all the various binaries in the serialpps-yyyymmdd.zip
> files work together, or have I missed a document download somewhere?
>
> The patched NTPD binaries continue to work OK lan/wan synched at the
> moment.
>
> Cheers.
>
> Dave Baxter.
Dave,
I have my GPS18 LVCs set to 4800 baud for Dave Hart's Windows version. I
don't know whether they will work with NTP at other rates.
Serial PPS - I can't be sure what documentation is included - I thought
there was enough. The serialpps.sys files are functional replacements for
the serial.sys driver supplied with Windows, there are both 32-bit and two
64-bit versions provided. These live along alongside the existing
serial.sys drivers, and a registry edit determines which is loaded at boot
time. You can swap back just by reverting the registry edit. Batch files
are provided to help with the registry edit.
There is only one version of the DLL (32-bit), and ntpd.exe will try to
call that DLL if a certain environment variable is set. Dave hart wrote:
________________________________
There's a new .dll there which ntpd currently finds by way of environment
variable PPSAPI_DLLS. If you put it in the same directory as ntpd.exe,
this should work
PPSAPI_DLLS=serialpps-ppsapi-provider.dll
you can also use a path:
PPSAPI_DLLS=c:\serialpps\serialpps-ppsapi-provider.dll
Keeping it out of the ntpd.exe directory avoids having it stepped on by
running the Meinberg installer.
________________________________
but that text isn't in the version I have (serialpps-20090606.zip). As
I've mentioned before, on the system I tested which some may say is
lightly loaded, adding the kernel-mode serialpps.sys routine did make some
improvement, but not a lot compared to having a PPS-sync rather than a
LAN-sync.
73,
David GM8ARV
G8KBV
tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid says...
Hi David..
OK on all that (4800 bd etc) I too at the moment run NTPD etc on a
"lightly loaded" machine. P4 1G 512Meg, not a lot else running other
than the Win 2k system. & I've got the reg' edited according to the
location of the serialpps-ppsapi-provider.dll OK too.
Have to say, that even just as a intermediary, the time keeping
performance of the system as a whole with a local ntp server, is vastly
superior than letting it all sync to external servers via the web. I
guess the time keeping algorithms in NTPD are somewhat more effecitve
than those in Faros itself.
All the best, hope to have more good news soon.
Dave Baxter.
David J Taylor
news:MPG.258e12bfc...@news.demon.co.uk...
[]
> Hi David..
>
> OK on all that (4800 bd etc) I too at the moment run NTPD etc on a
> "lightly loaded" machine. P4 1G 512Meg, not a lot else running other
> than the Win 2k system. & I've got the reg' edited according to the
> location of the serialpps-ppsapi-provider.dll OK too.
>
> Have to say, that even just as a intermediary, the time keeping
> performance of the system as a whole with a local ntp server, is vastly
> superior than letting it all sync to external servers via the web. I
> guess the time keeping algorithms in NTPD are somewhat more effecitve
> than those in Faros itself.
>
> All the best, hope to have more good news soon.
>
> Dave Baxter.
That's good news, Dave. You can be sure that the kernel-mode
serialpps.sys is working and connected if the ntpq -p display includes a
line:
oPPS(1) .PPS.
in addition to the basic serial GPS/PPS line:
*GPS_NMEA(1) .GPS.
It's a bit misleading because the GPS/PPS driver /does/ include the
PPS-over-DCD support, just at user-mode rather than kernel mode which is
supplied by the serialpps.sys.
One thing you can do for local systems is to poll them more frequently (an
unfriendly act with public Internet systems) and fix the polling rather
than let it automatically become less frequent. This reduces the offset
but may increase jitter slightly, but may be what you need if the
closeness to UTC is important. I have my LAN-synced systems set to poll
the local stratum-1 server at fixed 32-second intervals, and the remote
"last-chance" Internet servers at the normal variable 64-1024s interval.
IIRC you need 4.2.5 or later to have this mixed interval polling (so 4.2.6
and 4.2.7 should work as well).
I've heard the kernel-mode/PPS support also described as the "Atom"
driver, although I think that refers to some better filtering. Perhaps
someone could clarify that.
73,
David
Frank Wayne
> I have uploaded x86 Windows binaries for 4.2.6 to my website.
FYI, I downloaded the non-debug 4.2.6 binaries from your website and replaced the 4.2.4p7 Meinberg binaries on one of my Windows 2003 R2 x86 servers. When I started the service, it pegged my (single-core) Pentium 4 CPU and made the UI completely non-responsive. I couldn't even get Task Manager to respond. I had to power down manually and then started safe mode to copy the old binaries back.
Are there any special requirements for the binary you compiled?
Dave Hart
I guess so, based on your experience. I'm using the same binaries on
ntp.davehart.net, running ws2003 on x86 as well. The libeay32.dll is
from the prebuilt 0.9.8j package for Windows:
2009-01-07 14:40 1,097,728 libeay32.dll
I'd like to understand what's going wrong for you. With suitable
privilege, ntpd runs at realtime priority and if it gets into a
CPU-bound knot, it is expected it would make the rest of the machine
unusuable as you experienced. Typically, it uses very little CPU and
it appears you've uncovered a bug. You might try running the debug
binary interactively from an administrator command prompt with tracing
enabled (by adding -D2 to the command line, for example). If it
reproduces, the repeating output or the last few lines before the hang
might finger the culprit.
Cheers,
Dave Hart