Adventures with NTP and IPv6 in OpenWRT

Published on 2017-11-25 22:14:33

The situation: I would like to run an IPv6-only WiFi network at home (alongside the regular dual-stack WiFi network) as a bit of an experiment to see how viable an IPv6-only existence is at the moment, and partly to feel futuristic surfing the net without a v4 address.

Choosing a router

I had three routers to choose from: two off-the-shelf domestic boxes by TPLink and Asus, and the OpenWRT-based AR150 by GLiNet. The TPLink and Asus routers both support IPv6–indeed the TPLink is currently running my dual-stack WiFi network. Unfortunately they both require an IPv4 address in order to function, and I have not been able to persuade either of them to run with just v6. This leaves the little OpenWRT box, which should (in theory!) be easy enough to configure the way I want.


This was the easy part: the box has three network interfaces to configure, called lan, wan and wlan0. I kept the LAN interface configured as IPv4 with DHCP on the default subnet as a management/recovery interface whilst I was playing around with the other two interfaces. Then through LuCi I set WAN to be a DHCPv6 client only and bridged it to wlan0. ifconfig confirms that the interfaces are correctly configured as br-wan has a v6 address but no v4.

Time to connect to the access point and delight in the wonders that the modern internet has to offer!

...or not. Turns out the clock on the router was 5 minutes out. This problem manifested itself as a message in my laptop's syslog: No association and the time event is over already... which normally indicates a time mismatch.

Fixing NTP

The build of OpenWRT provided by GLiNet already includes ntpd running as a client with timeservers {0,1,2,3}, so why wasn't my time correct? Running ntpd manually as ntpd -n -d -q -p gave some explanation: it resolved an IPv4 peer and then failed with a "network is unreachable" message. The flags on ntpd are -d for verbose (i.e. debug mode); -n for "do not daemonise"–without this flag we do not get any error messages back in the terminal and just end up with extra ntpd processes that aren't doing anything; -q to quit after setting the clock, as we are running this as a once-off; and -p to tell ntpd which peer to connect to.

This was interesting. On a v6-only connection, why was ntpd trying to connect to a v4 peer? I eventually came upon a blog post by Stefan Lengfeld pointing to a post on the NTP pool news site noting that there are only AAAA records on the 2 variants of the various ntp pool addresses (so,, etc.). Why this is still the case I'm not quite sure, but I duly amended my call to ntpd to use

"Resolved peer ...Network is unreachable". Huh.

This is a known limitation of the busybox version of ntpd in which it will do a single dns lookup for a peer address and then try to connect to the first response. Unfortunately the first response happens to be a v4 address, so ntpd gets stuck trying to connect to it.

As a quick fix I called ntpd again, this time specifying a peer by its address (resolved via dig) and that gave me a one-off synchronisation but doesn't fix the main problem.