On 2/16/19 23:08, Jeffrey Walton wrote:
On Sat, Feb 16, 2019 at 10:35 PM David Kerr <[email protected]> wrote:
Erik, see here for a proposed fix. No response from the WireGuard team yet.
https://lists.zx2c4.com/pipermail/wireguard/2019-January/003842.html
Recently I had a power outage and both my gateway and cable modem went offline.
On power recovery both devices start up, but the gateway completes startup
before the cable modem completes its protocol negotiations, so initially the
external network (eth0) is not functional. That comes online say one minute
later and all is well.
Except that all is not well. Wireguard failed to start up because I have
Endpoint=<a URL> instead of a IP address. And because external interface is
not live yet, DNS lookup fails and Wireguard does not gracefully handle it. This is
really important because Wireguard may be my only way into my local network.
As work-around I replaced the URL with the IP address... but that is not a long
term solution if the endpoint is not a static IP address.
Wireguard needs to handle the situation where external network may not have
stabilized at the time it starts up. The above link proposed a fix.
Forgive my ignorance... Should init just retry the service start?
Something like this (from Systemd):
[Unit]
StartLimitInterval=360
StartLimitBurst=5
The statements above say to retry 5 times within 360 seconds.
Jeff
The issue is that the service shouldn't terminate over failure to
resolve an individual endpoint.
Suppose name resolution fails because of a DNS failure rather than a
network failure. If there are other endpoints configured by address that
are still reachable, should we give up entirely and not even connect the
ones that we can? What if one of the endpoints configured by IP address
is the DNS server?
Pushing this onto init would imply something like separate unit files
per endpoint, which may complicate things more than simplify them.
It seems like the conflict is that on the one hand, we want to resolve
the name at connection time rather than configuration time, but on the
other hand we don't want a DNS resolver in the kernel. How hard would it
be to call out to a trivial userspace DNS client? This shouldn't be very
performance sensitive, the results could be cached for the TTL which is
typically hours or at least minutes.
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
