Windows Client Can't Set MTU Below 1280

2022-11-04 Thread Clark Case
Hi All - I'm trying to set up a WireGuard tunnel via udp2raw. The
client side is running Windows, the server is the linuxserver docker
container

I can get the tunnel set up through udp2raw, I can ping across it, I
can use mosh across it, I can sometimes do ssh, but I can't get HTTP
either with a browser or with curl. Based on some input on reddit, I'm
trying to lower the MTU of the virtual adapter. However, the lower
limit that seems to be permitted by the client seems to be 1280 - and
1280 doesn't fix the problem. Below 1280, I get an error when trying
to activate the tunnel.

I'm assuming that this is because of some code in here:
https://github.com/WireGuard/wireguard-windows/blob/master/tunnel/mtumonitor.go

var minMTU uint32
if family == windows.AF_INET {
minMTU = 576
} else if family == windows.AF_INET6 {
minMTU = 1280
}
I'm not trying to do anything via IPV6, and I don't have an IPV6
address specified on the server side or the client side config files.
I've tried disabling IPV6 in the physical adapter the virtual adapter
is binding to, but I still get the error.

So, is there something else I should be doing to convince WireGuard
that I just want to do IPV4?


Re: absolutely terrible wireguard performance on a 4ghz box - need tuning help

2022-11-04 Thread Metin Evrim Ulu


Kyle Sanderson  writes:

> hi wireguard,
>
> APU2C4 - AMD Embedded G series GX-412TC, 1 GHz quad Jaguar core with
> 64 bit and AES-NI support
>

Um, I don't recall any Rijndael/AES in WG implementation, any particular
reason for mentioning AES-NI? 

best,
evrim.


Re: absolutely terrible wireguard performance on a 4ghz box - need tuning help

2022-11-04 Thread Daryl Richards

On 2022-10-25 2:58 a.m., Kyle Sanderson wrote:

hi wireguard,

APU2C4 - AMD Embedded G series GX-412TC, 1 GHz quad Jaguar core with
64 bit and AES-NI support

There has to be a way to improve this. I'm getting 20-40MB/s (causing
a system load of 6 on this poor box) where SSHFS in comparison is
still able to fly. Traffic not traversing the tunnel is also,
strangely, impacted as well. I have the Intel i210AT controller, which
doesn't appear to have any offloading to it when wireguard is present.

ksoftirqd/0 spins at around 50%, ksoftirqd/1 spins around 20%, and the
other 12(!) wg-crypt threads hover around 20% respectively.
If I disable wg I'm able to get line-rate through acceleration.
The other 2 ksoftirqds sit around 5% respectively. kworker events
jumping between 10-25%.

Regrettably openwrt doesn't appear to have perf available...


Perhaps this is an OpenWRT issue? I have a number of these APUs with 
astlinux installed, doing wireguard, and can easily do 300-400mbps, and 
that's across the internet so perhaps faster if on a test bench.


The APU isn't the problem..


[PATCH 1/2] ipc: freebsd: avoid leaking memory in kernel_get_device()

2022-11-04 Thread kevans
From: Kyle Evans 

Primarily, front-load validation of an allowed-ip entry to before we
allocate `aip`, so that we don't need to free() it if we end up skipping
this entry.  Assert that `aip` is NULL after we exit the loop, as we
should have transfered ownership to the `peer` or freed it in all paths
through the allowed-ip loop.

FreeBSD-Coverity:   1500405
Signed-off-by: Kyle Evans 
---
 src/ipc-freebsd.h | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/src/ipc-freebsd.h b/src/ipc-freebsd.h
index b5be15b..78064e9 100644
--- a/src/ipc-freebsd.h
+++ b/src/ipc-freebsd.h
@@ -8,6 +8,8 @@
 #include 
 #include 
 
+#include 
+
 #define IPC_SUPPORTS_KERNEL_INTERFACE
 
 static int get_dgram_socket(void)
@@ -118,7 +120,7 @@ static int kernel_get_device(struct wgdevice **device, 
const char *ifname)
goto skip_peers;
for (i = 0; i < peer_count; ++i) {
struct wgpeer *peer;
-   struct wgallowedip *aip;
+   struct wgallowedip *aip = NULL;
const nvlist_t *const *nvl_aips;
size_t aip_count, j;
 
@@ -169,11 +171,13 @@ static int kernel_get_device(struct wgdevice **device, 
const char *ifname)
if (!aip_count || !nvl_aips)
goto skip_allowed_ips;
for (j = 0; j < aip_count; ++j) {
+   if (!nvlist_exists_number(nvl_aips[j], "cidr"))
+   continue;
+   if (!nvlist_exists_binary(nvl_aips[j], "ipv4") && 
!nvlist_exists_binary(nvl_aips[j], "ipv6"))
+   continue;
aip = calloc(1, sizeof(*aip));
if (!aip)
goto err_allowed_ips;
-   if (!nvlist_exists_number(nvl_aips[j], "cidr"))
-   continue;
number = nvlist_get_number(nvl_aips[j], "cidr");
if (nvlist_exists_binary(nvl_aips[j], "ipv4")) {
binary = nvlist_get_binary(nvl_aips[j], "ipv4", 
);
@@ -184,7 +188,8 @@ static int kernel_get_device(struct wgdevice **device, 
const char *ifname)
aip->family = AF_INET;
aip->cidr = number;
memcpy(>ip4, binary, sizeof(aip->ip4));
-   } else if (nvlist_exists_binary(nvl_aips[j], "ipv6")) {
+   } else {
+   assert(nvlist_exists_binary(nvl_aips[j], 
"ipv6"));
binary = nvlist_get_binary(nvl_aips[j], "ipv6", 
);
if (!binary || number > 128) {
ret = EINVAL;
@@ -193,14 +198,14 @@ static int kernel_get_device(struct wgdevice **device, 
const char *ifname)
aip->family = AF_INET6;
aip->cidr = number;
memcpy(>ip6, binary, sizeof(aip->ip6));
-   } else
-   continue;
+   }
 
if (!peer->first_allowedip)
peer->first_allowedip = aip;
else
peer->last_allowedip->next_allowedip = aip;
peer->last_allowedip = aip;
+   aip = NULL;
continue;
 
err_allowed_ips:
@@ -209,6 +214,12 @@ static int kernel_get_device(struct wgdevice **device, 
const char *ifname)
free(aip);
goto err_peer;
}
+
+   /*
+* Nothing leaked, hopefully -- ownership transferred or aip
+* freed.
+*/
+   assert(aip == NULL);
skip_allowed_ips:
if (!dev->first_peer)
dev->first_peer = peer;
-- 
2.36.1



[PATCH 2/2] ipc: freebsd: NULL out some freed memory in kernel_set_device()

2022-11-04 Thread kevans
From: Kyle Evans 

The `err` path in kernel_set_device() will attempt to free() allocated
nvl_peers, but these two cases meant we could end up attempting a use
after free or a double free, as we rely on nvlist_destroy(NULL) being
a NOP as well as free(NULL).

FreeBSD-Coverity:   1500421
Signed-off-by: Kyle Evans 
---
 src/ipc-freebsd.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/ipc-freebsd.h b/src/ipc-freebsd.h
index 78064e9..f9d3550 100644
--- a/src/ipc-freebsd.h
+++ b/src/ipc-freebsd.h
@@ -333,6 +333,7 @@ static int kernel_set_device(struct wgdevice *dev)
nvlist_destroy(nvl_aips[j]);
free(nvl_aips);
nvlist_destroy(nvl_peers[i]);
+   nvl_peers[i] = NULL;
goto err;
}
if (i) {
@@ -340,9 +341,11 @@ static int kernel_set_device(struct wgdevice *dev)
for (i = 0; i < peer_count; ++i)
nvlist_destroy(nvl_peers[i]);
free(nvl_peers);
+   nvl_peers = NULL;
}
wgd.wgd_data = nvlist_pack(nvl_device, _size);
nvlist_destroy(nvl_device);
+   nvl_device = NULL;
if (!wgd.wgd_data)
goto err;
s = get_dgram_socket();
-- 
2.36.1



absolutely terrible wireguard performance on a 4ghz box - need tuning help

2022-11-04 Thread Kyle Sanderson
hi wireguard,

APU2C4 - AMD Embedded G series GX-412TC, 1 GHz quad Jaguar core with
64 bit and AES-NI support

There has to be a way to improve this. I'm getting 20-40MB/s (causing
a system load of 6 on this poor box) where SSHFS in comparison is
still able to fly. Traffic not traversing the tunnel is also,
strangely, impacted as well. I have the Intel i210AT controller, which
doesn't appear to have any offloading to it when wireguard is present.

ksoftirqd/0 spins at around 50%, ksoftirqd/1 spins around 20%, and the
other 12(!) wg-crypt threads hover around 20% respectively.
If I disable wg I'm able to get line-rate through acceleration.
The other 2 ksoftirqds sit around 5% respectively. kworker events
jumping between 10-25%.

Regrettably openwrt doesn't appear to have perf available...

K.