Need for HW-clock independent timestamps

Paul paul at
Thu May 17 05:40:55 CEST 2018

Hi all,

If I'm not mistaken replay attacks are checked here [1] and only 
compare integers with no reference to local time of the receiving node.

The sending nodes timestamp is generated via tai64n_now [2][3]. From my 
understanding this function could simply be changed to a auto increased 
counter, periodically saved on disc and increased on boot, following 
the approach described by Axel Neumann[4]. Mixing real timestamps and 
counter should be compatible to one another. Only drawback is see is 
that the overview function is likely mixed up [5].

All could be done by a patch specifically for HW-clock less devices or 
added to OpenWrt buildroot only[6].

Any reasons why such a patch could be bad?


Just a few thoughts regarding GPS:

On Thu, May 17, 2018 at 5:32 AM, Steve Gilberd <steve at> wrote:
> > $20 would increase the HW cost of many typical community-networks 
> (CN) deployments significantly.
> This seems unlikely. In most cases, $20 is notably less than the cost 
> of a single node.

I'd doubt that. People massively use TP-Link 841 (~20$, 100%) or 
Uqiquity Nanobeams (~60$, 34%) as node hardware.

> > Plus requiering more knowledge, maintenence, and power supply for 
> sometimes solar-powered setups... no USB.
> If that's a concern, then put the GPS on nodes where those 
> constraints aren't a problem. You only need GPS on a few nodes (or 
> one node if you don't care about redundancy). Most nodes will get by 
> just fine with just plain NTP, and can happily fetch their time from 
> the GPS nodes, or from other non-GPS nodes with a correct time sync.

This was already answered and found as unusable as it introduces 
additional configuration of all nodes, firewall rules, etc?

> > It is really NOT as simple as it sounds to plug a $20 GPS !!!
> It's not particularly complicated either. The actual setup of the 
> devices isn't particularly difficult, and you're already touching 
> these nodes to set up wireguard on them, so "I have to touch the 
> config" isn't a barrier in this case.

Opening and closing (in a waterproof manner) the previously mentioned 
Nanobeam is not particularly trivial. Also it introduces a whole stack 
of device specific knowledge. As stated before, this changes the 
configuration from "enter wireguard credentials" to "{open, buy 
additional, glue} hardware, setup {wireguard, gps, more?}.

For me it looks like a problem solvable in software (as done for the 
BMX routing protocol). Why even bother to get hardware involved?


More information about the WireGuard mailing list