Need for HW-clock independent timestamps

Matthias Urlichs matthias at
Sun May 13 08:11:57 CEST 2018

On 12.05.2018 21:29, Axel Neumann wrote:
> Thanks a lot for your replies. But as you can see from my comments below
> this all does not look like a valid option for many embedded use cases.
> BTW, my background are community mesh networks which are maintained by
> all kind of different individuals using a zoo of different device types.
> I would really appreciate if WG can further elaborate on this issue.
> There are many real-life communities with embedded-device deployments
> that would be looking forward to use WG.
> Could you also comment on the described approach (see again at the end
> of the mail) of allowing (maybe as an alternative) a sequence number
> instead of a timestamp?
What's the problem? the protocol documentation states

> The server keeps track of the greatest timestamp received /per client/
> and discards packets containing timestamps less than or equal to it.

I just checked the C implementation; it does this check (and no others).
In particular it doesn't check whether the timestamp field corresponds
to anybody's idea of the current time.

Thus you don't need current time; you just need to seed a counter. I
would thus add an option to wg.conf that, if present, sets the
interface's current timestamp to some value and uses it as a counter
instead of a timestamp.

Then, when you set up your WG instance, you should immediately rewrite
your wg.conf file (just add 2^32) so that a reboot doesn't DoS yourself.
Additionally, when you acquire NTP sync, set the parameter to the
TAI64N() of the current time. To be extra safe, repeat this every week
or month or so.

Can anybody think of problems with this solution?

-- Matthias Urlichs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the WireGuard mailing list