Flood ping can cause oom when handshake fails

[Yousong Zhou]

On 22 September 2017 at 21:19, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> Hi Yousong,
>
> Thanks for the report.
>
> On Fri, Sep 22, 2017 at 2:58 PM, Yousong Zhou <yszhou4tech at gmail.com> 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
>
>
> The handshake will not actually occur until you try to send data over
> the interface. So after bringing the interface up, send a ping. Then
> you'll have the handshake. If you'd like the handshake to happen
> immediately and for packets in general to persistently be sent, to,
> for example, keep NAT mappings alive, there's the persistent-keepalive
> option. See the wg(8) man page for details.
>
>>  - Wireguard packets can be captured on eth0.1 but not on the remote
>
> I'm not sure I understood this point. Can you elaborate?

The VoCore device has a built-in switch and as I understand the cpu
port of which will be present as eth0 in the Linux system.  Port 4 of
the switch was configured to belong to VLAN 1 and will be present as
eth0.1.

Default route in the main table points to eth0.1 and traffic flows
through it just fine.  I have the following observations when
handshake fails

 - I can send udp traffic with netcat from my laptop to the remote
peer's endpoint.  The traffic can be captured on the remote and
ignored as expected.  This means the traffic to the remote endpoint
can go through eth0.1 just fine
 - I can also capture wireguard traffic on eth0.1 with tcpdump, but
the same traffic cannot be captured on the remote which means that the
udp traffic sent from the kernel very likely failed to be sent out on
wire.

                yousong