Skip to main content

Alpha This is a new website theme. Help me improve it and give your feedback (opens in a new tab).

OpenBSD with GPS synchronised NTP

Published:

Tags:

Sysadmin Hacking Openbsd Ntp Gps
This blog post is more than two years 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.

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).

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).

When you attach this to OpenBSD, it is recognised 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 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

(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:

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

Update 2020-09-28: Evaldas Auryla has an excellent write up inspired by this post with OpenBSD running on an Orange Pi Zero with a U-Blox M8N GPS module from Ali Express.

Contact