Flood ping can cause oom when handshake fails

Yousong Zhou yszhou4tech at gmail.com
Fri Sep 22 14:58:22 CEST 2017

Hi, I have encountered a few issues when running WireGuard on VoCore:
a small ramips device with 16MB flash and 32MB ram

  root at LEDE:/# uname -a
  Linux LEDE 4.9.49 #0 Fri Sep 15 05:14:29 2017 mips GNU/Linux
  root at LEDE:/# opkg list-installed | grep -i wireguard
  kmod-wireguard - 4.9.49+0.0.20170907-1
  luci-app-wireguard - git-17.259.19938-f36f198-1
  luci-proto-wireguard - git-17.259.19938-f36f198-1
  wireguard - 0.0.20170907-1
  wireguard-tools - 0.0.20170907-1
  root at LEDE:/# wg show
  interface: air
    public key: eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
    private key: (hidden)
    listening port: 21841

  peer: ffffffffffffffffffffffffffffffffffffffffffff
    endpoint: iiiiiiiiiiii:ppppp
    allowed ips:
    latest handshake: 4 minutes, 35 seconds ago
    transfer: 520 B received, 872 B sent

WAN is a wired vlan interface: eth0.1 bearing the default route.
Traffics will be marked by iptable rules and routed through wireguard
interface with simple policy routing rules.  The setup works quite
well on another ar71xx-based device (in case it matters, the wan
interface is a regular device eth1).

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 packets can be captured on eth0.1 but not on the remote

The second issue is that when handshake fails, flood ping traffic that
was expected to be forwarded through the wireguard interface can cause
oom and hang the device to death.  There is a [kworker] process taking
up high cpu usage.

WireGuard is a very nice and convenient solution.  If there are any
further steps/info required to debug this, I am all ready ;)


More information about the WireGuard mailing list