diff options
| author |   Jason A. Donenfeld <Jason@zx2c4.com> | 2016-07-08 14:26:25 +0200 |
|---|---|---|
| committer | Jason A. Donenfeld <Jason@zx2c4.com> | 2016-07-08 14:28:15 +0200 |
| commit | dcc2583fe0618931e51aedaeeddde356d123acb2 (patch) | |
| tree | c9e6dfe3c744143daa2f966ab005f39dee52fc00 /src/device.c | |
| parent | persistent keepalive: enable in an example (diff) | |
| download | wireguard-monolithic-historical-dcc2583fe0618931e51aedaeeddde356d123acb2.tar.xz wireguard-monolithic-historical-dcc2583fe0618931e51aedaeeddde356d123acb2.zip | |
persistent keepalive: start sending immediatelyexperimental-0.0.20160708.1
Rather than only start sending the persistent keepalive packets when the
device first sends data, this changes it to send the packets immediately
on `ip link set up`. This makes things generally seem more stateless,
since the administrator does not have to manually ping the endpoint.
Of course, if you have a lot of peers and all of them have persistent
keepalive enabled, this could cause a lot of unwanted immediate traffic.
On the other hand, if all of those peers are at some point going to be
sending packets, this would happen anyway. I suppose the moral of the
story is that persistent keepalive is a feature really just for clients
behind NAT, not for servers, and it should be used sparingly, which is
why we've set it off by default in the first place.
Diffstat (limited to 'src/device.c')
| -rw-r--r-- | src/device.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/src/device.c b/src/device.c index 120f8c9..198368f 100644 --- a/src/device.c +++ b/src/device.c @@ -40,6 +40,8 @@ static int open_peer(struct wireguard_peer *peer, void *data) socket_set_peer_dst(peer); timers_init_peer(peer); packet_send_queue(peer); + if (peer->persistent_keepalive_interval) + socket_send_buffer_to_peer(peer, NULL, 0, 0); return 0; } |