[PATCH 1/2] build/tools: Add support for Haiku

[PATCH 1/2] build/tools: Add support for Haiku

[Alexander von Gluck IV]

---
 src/tools/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/tools/Makefile b/src/tools/Makefile
index f2904f2..0eecc57 100644
--- a/src/tools/Makefile
+++ b/src/tools/Makefile
@@ -51,6 +51,9 @@ LIBMNL_LDLIBS := $(shell $(PKG_CONFIG) --libs libmnl 2>/dev/null || echo -lmnl)
 CFLAGS += $(LIBMNL_CFLAGS)
 LDLIBS += $(LIBMNL_LDLIBS)
 endif
+ifeq ($(PLATFORM),haiku)
+LDLIBS += -lnetwork -lbsd
+endif
 
 ifneq ($(V),1)
 BUILT_IN_LINK.o := $(LINK.o)
-- 
2.20.1

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

[PATCH 2/2] genkey: v2. Be more aggressive in the search for entropy

[Alexander von Gluck IV]

* If we don't get the amount of entropy we were looking for,
  go back to the pool several times. Haiku seems to only
  provide up to 16 bytes per urandom access resulting in
  weird behaviour in this code.
* Prevents one of those lovely "error: success" errors when
  no entropy can be had from /dev/urandom
---
 src/tools/genkey.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/src/tools/genkey.c b/src/tools/genkey.c
index 645f614..67c4752 100644
--- a/src/tools/genkey.c
+++ b/src/tools/genkey.c
@@ -29,7 +29,7 @@
 
 static inline ssize_t get_random_bytes(uint8_t *out, size_t len)
 {
-	ssize_t ret;
+	ssize_t ret = 0;
 	int fd;
 
 #if defined(__OpenBSD__) || (defined(__APPLE__) && MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_X_VERSION_10_12) || (defined(__GLIBC__) && (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 25)))
@@ -47,7 +47,18 @@ static inline ssize_t get_random_bytes(uint8_t *out, size_t len)
 	fd = open("/dev/urandom", O_RDONLY);
 	if (fd < 0)
 		return fd;
-	ret = read(fd, out, len);
+
+	int attempts = 0;
+	while (ret < len) {
+		ssize_t remaining = len - ret;
+		ret += read(fd, out + ret, remaining);
+		if (attempts > 64) {
+			fprintf(stderr, "Unable to get enough entropy from /dev/urandom!");
+			close(fd);
+			return -1;
+		}
+		attempts++;
+	}
 	close(fd);
 	return ret;
 }
@@ -70,6 +81,7 @@ int genkey_main(int argc, char *argv[])
 		perror("getrandom");
 		return 1;
 	}
+
 	if (!strcmp(argv[0], "genkey"))
 		curve25519_clamp_secret(key);
 
-- 
2.20.1

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [PATCH 1/2] build/tools: Add support for Haiku

[Jason A. Donenfeld]

May I apply this with your signed-off-by line?

Namely:

Signed-off-by: Alexander von Gluck IV <kallisti5@unixzen.com>
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Single CPU core bottleneck caused by high site-to-site traffic

[Xiaozhou Liu]

Hi Jason and the list,

Here at our corporate network we run some inner site-to-site VPNs using
WireGuard. Thanks for giving out such a beautiful software to the world.

Recently we encountered some noticeable network latency during peak traffic
time. Although the traffic is pretty huge, the WireGuard box is far from
running out of any of its resources: CPU, memory, network bandwidth, etc.

It turns out that the bottleneck is caused by the single UDP connection
between the sites, which cannot be routed to different CPU cores by RSS
on receiving. The total CPU usage is not high, but one of the cores can
reach 100%.

Maybe we can improve this by:

  embedding more endpoints in one peer so that the VPN tunnel can run
  multiple UDP flows instead of one. Hence, the single huge UDP flow is
  effectively broken down to some smaller ones which can be received by
  multiple queues of the NIC and then later processed by more CPU cores.
  It will not break current users because the single UDP connection is
  still provided as the default configuration.

It is also possible to set up multiple wg interfaces and more connections
explicitly. But it would make the network administration much more complex.

We are planning to make a working demo of this idea but we would like to
hear from you first.

Any idea or comment is appreciated.


Thanks,
Xiaozhou
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Single CPU core bottleneck caused by high site-to-site traffic

[Samuel Holland]

On 03/01/19 22:24, Xiaozhou Liu wrote:
> Hi Jason and the list,
> 
> Here at our corporate network we run some inner site-to-site VPNs using
> WireGuard. Thanks for giving out such a beautiful software to the world.
> 
> Recently we encountered some noticeable network latency during peak traffic
> time. Although the traffic is pretty huge, the WireGuard box is far from
> running out of any of its resources: CPU, memory, network bandwidth, etc.
> 
> It turns out that the bottleneck is caused by the single UDP connection
> between the sites, which cannot be routed to different CPU cores by RSS
> on receiving. The total CPU usage is not high, but one of the cores can
> reach 100%.
> 
> Maybe we can improve this by:
> 
>   embedding more endpoints in one peer so that the VPN tunnel can run
>   multiple UDP flows instead of one. Hence, the single huge UDP flow is
>   effectively broken down to some smaller ones which can be received by
>   multiple queues of the NIC and then later processed by more CPU cores.
>   It will not break current users because the single UDP connection is
>   still provided as the default configuration.

While a native solution would be nice, you should be able to do this today with
nftables. Dynamically rewrite the port number on a portion of the outgoing
packets, and redirect that additional port to the main port on the receive side.
This (untested) is based on the examples in the nftables wiki[1]:

$ nft add rule nat output ip daddr $OTHER_PEER udp dport $MAIN_PORT \
	dnat to $PEER : numgen inc mod 2 map { \
               0 : $MAIN_PORT ,\
               1 : $ALT_PORT \
	}
$ nft add rule nat prerouting ip daddr $MY_IP udp dport $ALT_PORT \
	redirect to $MAIN_PORT

[1]: https://wiki.nftables.org/wiki-nftables/index.php/Load_balancing

> It is also possible to set up multiple wg interfaces and more connections
> explicitly. But it would make the network administration much more complex.
> 
> We are planning to make a working demo of this idea but we would like to
> hear from you first.
> 
> Any idea or comment is appreciated.
> 
> 
> Thanks,
> Xiaozhou

Regards,
Samuel

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

[PATCH 1/2] build/tools: Add support for Haiku

[Alexander von Gluck IV]

---
 src/tools/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/tools/Makefile b/src/tools/Makefile
index f2904f2..0eecc57 100644
--- a/src/tools/Makefile
+++ b/src/tools/Makefile
@@ -51,6 +51,9 @@ LIBMNL_LDLIBS := $(shell $(PKG_CONFIG) --libs libmnl 2>/dev/null || echo -lmnl)
 CFLAGS += $(LIBMNL_CFLAGS)
 LDLIBS += $(LIBMNL_LDLIBS)
 endif
+ifeq ($(PLATFORM),haiku)
+LDLIBS += -lnetwork -lbsd
+endif
 
 ifneq ($(V),1)
 BUILT_IN_LINK.o := $(LINK.o)
-- 
2.20.1

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard