I've just tried running xntpd on my current-ish netbsd/i386 and it doesn't
seem to work too well :-(

There is a stratum 3 ntp server running version xntp-3.5f on the local network,
on a Solaris 2.5 system.  Other xntp-3.5f clients running on the network work
fine.

My ntp.conf file looks like

	broadcastclient yes
	broadcastdelay 0.008
	driftfile /etc/ntp.drift

It was stolen verbatim from another client on our network!

Running NetBSD's xntpd in debug mode (-dddd) gives the following output
every 30 seconds or so.

	sendpkt(fd=5 130.195.5.20, 130.195.5.87, ttl=-8, 48)
	transmit to 130.195.5.20
	input_handler: fd=5 length 48 from 82c30514 130.195.5.20
	receive from 130.195.5.20
	receive: his mode 4
	poll_update(130.195.5.20, 6, 1)
	invalid packet header 130.195.5.20 0x10 0.324448 0.130676

The NetBSD xntpd identifies itself as "5.90 3-NetBSD Thu Apr 17 17:15:47
EDT 1997 (1)", so I don't know how that compares to the 3.5f that we are
running elsewhere.

The xntpdc "peers" command gives the following output

        remote           local      st poll reach  delay   offset    disp
   =======================================================================
   =kaukau.mcs.vuw. 130.195.5.255   16   64    0 0.00000  0.000000 16.0000

and the "sysinfo" command says

	system peer:          0.0.0.0
	system peer mode:     unspec
	leap indicator:       11
	stratum:              16
	precision:            -18
	root distance:        0.00000 s
	root dispersion:      0.00000 s
	reference ID:         [0.0.0.0]
	reference time:       00000000.00000000  Thu, Feb  7 2036 19:28:16.000
	system flags:         bclient auth monitor pll stats kernel_sync 
	frequency:            0.000 ppm
	stability:            0.000 ppm
	broadcastdelay:       0.007996 s
	authdelay:            0.000122 s

If I build and run xntpd-3.5f on my NetBSD system it seems to work properly
(ie, it doesn't get the above "invalid packet" message; and "peers" reports

       remote           local      st poll reach  delay   offset    disp
  =======================================================================
  =kaukau.mcs.vuw. 130.195.5.255    3   64    1 0.00000  0.000000 16.0000

The fact that it has identified kaukau as a stratum 3 server seems to be
better.

Are there any NTP guru's out there [Jonathan... :-)] who could shed some light
on what is going on here or tell me where to look to debug the problem
further...

Thanks.

Duncan