Internal ntp: Difference between revisions

From lippmann wiki
Jump to navigation Jump to search
(Created page with "much of this is taken from https://iain.learmonth.me/blog/2018/2018w437/ copied here for preservation reasons. OpenBSD with GPS synchronised NTP This blog post is more than...")
 
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 4: Line 4:
OpenBSD with GPS synchronised NTP
OpenBSD with GPS synchronised NTP


This blog post is more than a year old. It is preserved here in the hope that it is useful to someone, but please be aware that links may be broken and that opinions expressed here may not reflect my current views. If this is a technical article, it may no longer reflect current best practice.
Synchronizing time with servers on the Internet isn’t that exciting, but I’ve had a USB GPS dongle sitting doing nothing for a while. I originally purchased it to use with amateur radio projects but I haven’t done much radio recently. It looks like you can pick these up on eBay for around £11.00 and the newer ones also support GLONASS (mine only does GPS as far as I can tell).


I wrote on Monday about how I’ve swapped my home router for an OpenBSD box. One of the fun things I’ve done with this box is configure it as a network time server using ntpd(8).
When you attach this to OpenBSD, it is recognized as:


Synchronising time with servers on the Internet isn’t that exciting, but I’ve had a USB GPS dongle sitting doing nothing for a while. I originally purchased it to use with amateur radio projects but I haven’t done much radio recently. It looks like you can pick these up on eBay for around £11.00 and the newer ones also support GLONASS (mine only does GPS as far as I can tell).
umodem0 at uhub0 port 4 configuration 1 interface 0 "u-blox AG - www.u-blox.com u-blox 6  -  GPS Receiver" rev 1.10/7.03 addr 2
umodem0: data interface 1, has CM over data, has no break
umodem0: status change notification available
ucom0 at umodem0


When you attach this to OpenBSD, it is recognised as:
In Linux, I would use gpsd which is userland software and overkill for what is needed to get time out of the device. Instead, OpenBSD provides the nmea(4) line discipline that can be attached to the serial port with only a single line of configuration in /etc/ttys:


umodem0 at uhub0 port 4 configuration 1 interface 0 "u-blox AG - www.u-blox.com u-blox 6 -  GPS Receiver" rev 1.10/7.03 addr 2
  cuaU0  "/sbin/ldattach nmea"  unknown on softcar
umodem0: data interface 1, has CM over data, has no break
umodem0: status change notification available
ucom0 at umodem0
 
In Linux, I would use gpsd which is userland software and overkill for what is needed to get time out of the device. Instead, OpenBSD provides the nmea(4) line discipline that can be attached to the serial port with only a single line of configuration in /etc/ttys:


cuaU0   "/sbin/ldattach nmea"  unknown on softcar
Now when I run
   kill -s HUP 1
(or reboot) and run sysctl hw.sensors:


Now when I reboot and run sysctl hw.sensors:
hw.sensors.nmea0.indicator0=On (Signal), OK
hw.sensors.nmea0.timedelta0=-0.001002 secs (GPS autonomous), OK, Sun Oct 28 17:08:04.998
hw.sensors.nmea0.angle0=57.3748 degrees (Latitude), OK
hw.sensors.nmea0.angle1=-2.3849 degrees (Longitude), OK


hw.sensors.nmea0.indicator0=On (Signal), OK
hw.sensors.nmea0.timedelta0=-0.001002 secs (GPS autonomous), OK, Sun Oct 28 17:08:04.998
hw.sensors.nmea0.angle0=57.3748 degrees (Latitude), OK
hw.sensors.nmea0.angle1=-2.3849 degrees (Longitude), OK


(Update 2019-04-04: You don’t actually have to reboot. One reader has pointed out that you can instead kill -s HUP 1 and init(8) will re-read /etc/ttys.)


This was so incredibly simple I couldn’t believe that was it. If you have ntpd enabled, it will automatically pick up this new sensor too and start using it. I wanted to give a greater weight to my GPS clock than to random servers on the Internet though so I did add a line to /etc/ntpd.conf:
This was so incredibly simple I couldn’t believe that was it. If you have ntpd enabled, it will automatically pick up this new sensor too and start using it. I wanted to give a greater weight to my GPS clock than to random servers on the Internet though so I did add a line to /etc/ntpd.conf:


sensor nmea0 weight 5 refid GPS
sensor nmea0 weight 5 refid GPS


By default all sources have a weight of 1. Giving the GPS a weight of 5 gives it 5× the influence over the clock compared to servers from pool.ntp.org. The reference seems to be passed to clients but I’m not entirely sure yet what its significance is.
By default all sources have a weight of 1. Giving the GPS a weight of 5 gives it 5× the influence over the clock compared to servers from pool.ntp.org. The reference seems to be passed to clients but I’m not entirely sure yet what its significance is.
Line 40: Line 38:
I did spot that I can advertise my RFC868 time server too, so I set up both that and a daytime server using inetd(8) by adding to my /etc/inetd.conf:
I did spot that I can advertise my RFC868 time server too, so I set up both that and a daytime server using inetd(8) by adding to my /etc/inetd.conf:


daytime stream tcp nowait nobody internal
daytime stream tcp nowait nobody internal
time stream tcp nowait nobody internal
time stream tcp nowait nobody internal

Latest revision as of 14:16, 1 June 2020

much of this is taken from https://iain.learmonth.me/blog/2018/2018w437/ copied here for preservation reasons.

OpenBSD with GPS synchronised NTP

Synchronizing time with servers on the Internet isn’t that exciting, but I’ve had a USB GPS dongle sitting doing nothing for a while. I originally purchased it to use with amateur radio projects but I haven’t done much radio recently. It looks like you can pick these up on eBay for around £11.00 and the newer ones also support GLONASS (mine only does GPS as far as I can tell).

When you attach this to OpenBSD, it is recognized as:

umodem0 at uhub0 port 4 configuration 1 interface 0 "u-blox AG - www.u-blox.com u-blox 6  -  GPS Receiver" rev 1.10/7.03 addr 2
umodem0: data interface 1, has CM over data, has no break
umodem0: status change notification available
ucom0 at umodem0

In Linux, I would use gpsd which is userland software and overkill for what is needed to get time out of the device. Instead, OpenBSD provides the nmea(4) line discipline that can be attached to the serial port with only a single line of configuration in /etc/ttys:

cuaU0   "/sbin/ldattach nmea"   unknown on softcar

Now when I run

 kill -s HUP 1 

(or reboot) and run sysctl hw.sensors:

hw.sensors.nmea0.indicator0=On (Signal), OK
hw.sensors.nmea0.timedelta0=-0.001002 secs (GPS autonomous), OK, Sun Oct 28 17:08:04.998
hw.sensors.nmea0.angle0=57.3748 degrees (Latitude), OK
hw.sensors.nmea0.angle1=-2.3849 degrees (Longitude), OK


This was so incredibly simple I couldn’t believe that was it. If you have ntpd enabled, it will automatically pick up this new sensor too and start using it. I wanted to give a greater weight to my GPS clock than to random servers on the Internet though so I did add a line to /etc/ntpd.conf:

sensor nmea0 weight 5 refid GPS

By default all sources have a weight of 1. Giving the GPS a weight of 5 gives it 5× the influence over the clock compared to servers from pool.ntp.org. The reference seems to be passed to clients but I’m not entirely sure yet what its significance is.

In RFC2132 there is a DHCP option defined for advertising NTP servers, so I advertised the server via this mechanism. Thinking more about it, I’m hoping that nothing is automatically configuring itself using this DHCP option as that seems like something that shouldn’t get reconfigured just because you joined a network. There’s a lot of different options defined in this document and I wonder just how many of them are actually used/useful.

I did spot that I can advertise my RFC868 time server too, so I set up both that and a daytime server using inetd(8) by adding to my /etc/inetd.conf:

daytime stream tcp nowait nobody internal
time stream tcp nowait nobody internal