Fwd: Flood ping can cause oom when handshake fails

Yousong Zhou yszhou4tech at gmail.com
Fri Sep 22 15:53:33 CEST 2017

Sorry, my previous mail dropped off list accidentally.


---------- Forwarded message ----------
From: Yousong Zhou <yszhou4tech at gmail.com>
Date: 22 September 2017 at 21:22
Subject: Re: Flood ping can cause oom when handshake fails
To: Aaron Jones <aaronmdjones at gmail.com>

On 22 September 2017 at 21:15, Aaron Jones <aaronmdjones at gmail.com> wrote:
> Hash: SHA256
> On 22/09/17 12:58, Yousong Zhou wrote:
>> The first issue is that occasionally wireguard failed to send
>> handshake initiation packets to the remote.  I got to this
>> conclusion by two observations
>> - Tearing down then bringing up ("ifup air") the local wireguard
>> device did not trigger the update of "latest handshake" timestamp
>> on the remote
> WireGuard does not negotiate sessions when the interface is configured,
> it negotiates when it is required to do so (when you send a packet to
> the tunnel address of the peer, and there is no session with that peer),
> so if you want to see if negotiation is being performed, issue a ping
> immediately after reconfiguring the interface.
>> - Wireguard packets can be captured on eth0.1 but not on the
>> remote

Yes, I am aware of the "silence is a virtue" feature in the technical
paper.  That's why I kept (flood) pinging, trying to trigger the
handshake.  Tearing down and bringing up the interface was to make
sure that the udp traffic captured on eth0.1 is about handshake setup,
not data packets.


More information about the WireGuard mailing list