* [PATCH 1/2] build/tools: Add support for Haiku @ 2019-02-28 19:05 Alexander von Gluck IV 2019-02-28 19:05 ` [PATCH 2/2] genkey: v2. Be more aggressive in the search for entropy Alexander von Gluck IV 2019-03-01 19:54 ` [PATCH 1/2] build/tools: Add support for Haiku Jason A. Donenfeld 0 siblings, 2 replies; 5+ messages in thread From: Alexander von Gluck IV @ 2019-02-28 19:05 UTC (permalink / raw) To: wireguard --- 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 2/2] genkey: v2. Be more aggressive in the search for entropy 2019-02-28 19:05 [PATCH 1/2] build/tools: Add support for Haiku Alexander von Gluck IV @ 2019-02-28 19:05 ` Alexander von Gluck IV 2019-03-01 19:54 ` [PATCH 1/2] build/tools: Add support for Haiku Jason A. Donenfeld 1 sibling, 0 replies; 5+ messages in thread From: Alexander von Gluck IV @ 2019-02-28 19:05 UTC (permalink / raw) To: wireguard * 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/2] build/tools: Add support for Haiku 2019-02-28 19:05 [PATCH 1/2] build/tools: Add support for Haiku Alexander von Gluck IV 2019-02-28 19:05 ` [PATCH 2/2] genkey: v2. Be more aggressive in the search for entropy Alexander von Gluck IV @ 2019-03-01 19:54 ` Jason A. Donenfeld 2019-03-02 4:24 ` Single CPU core bottleneck caused by high site-to-site traffic Xiaozhou Liu 1 sibling, 1 reply; 5+ messages in thread From: Jason A. Donenfeld @ 2019-03-01 19:54 UTC (permalink / raw) To: Alexander von Gluck IV; +Cc: WireGuard mailing list 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Single CPU core bottleneck caused by high site-to-site traffic 2019-03-01 19:54 ` [PATCH 1/2] build/tools: Add support for Haiku Jason A. Donenfeld @ 2019-03-02 4:24 ` Xiaozhou Liu 2019-03-09 0:16 ` Samuel Holland 0 siblings, 1 reply; 5+ messages in thread From: Xiaozhou Liu @ 2019-03-02 4:24 UTC (permalink / raw) To: Jason A. Donenfeld Cc: duanxiongchun, wangdongdong.6, zhangyongsu, wireguard, wangjian 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Single CPU core bottleneck caused by high site-to-site traffic 2019-03-02 4:24 ` Single CPU core bottleneck caused by high site-to-site traffic Xiaozhou Liu @ 2019-03-09 0:16 ` Samuel Holland 0 siblings, 0 replies; 5+ messages in thread From: Samuel Holland @ 2019-03-09 0:16 UTC (permalink / raw) To: Xiaozhou Liu, Jason A. Donenfeld Cc: zhangyongsu, wangdongdong.6, duanxiongchun, wireguard, wangjian 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-03-09 0:16 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-02-28 19:05 [PATCH 1/2] build/tools: Add support for Haiku Alexander von Gluck IV 2019-02-28 19:05 ` [PATCH 2/2] genkey: v2. Be more aggressive in the search for entropy Alexander von Gluck IV 2019-03-01 19:54 ` [PATCH 1/2] build/tools: Add support for Haiku Jason A. Donenfeld 2019-03-02 4:24 ` Single CPU core bottleneck caused by high site-to-site traffic Xiaozhou Liu 2019-03-09 0:16 ` Samuel Holland
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).