From jirislaby at kernel.org Tue Nov 1 05:58:05 2022 From: jirislaby at kernel.org (Jiri Slaby) Date: Tue, 1 Nov 2022 06:58:05 +0100 Subject: [PATCH] wireguard (gcc13): cast enum limits members to int in prints In-Reply-To: References: <20221031114424.10438-1-jirislaby@kernel.org> Message-ID: <29259fbf-ee4c-764e-8158-274bb3914b9f@kernel.org> Hi, On 31. 10. 22, 14:07, Jason A. Donenfeld wrote: > On Mon, Oct 31, 2022 at 12:44:24PM +0100, Jiri Slaby (SUSE) wrote: >> Since gcc13, each member of an enum has the same type as the enum [1]. And >> that is inherited from its members. Provided "REKEY_AFTER_MESSAGES = 1ULL >> << 60", the named type is unsigned long. >> >> This generates warnings with gcc-13: >> error: format '%d' expects argument of type 'int', but argument 6 has type 'long unsigned int' >> >> Cast the enum members to int when printing them. >> >> Alternatively, we can cast it to ulong (to silence gcc < 12) and use %lu. >> Alternatively, we can move REKEY_AFTER_MESSAGES away from the enum. >> >> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113 > > Huh, interesting situation. It's interesting that 1<<60 even works at > all on old gccs. I guess that in this case, it just takes the type of > the actual constant, rather than of the enum type? Exactly, on gcc <= 12, every enum member has a type depending solely on its value. And yes, using anything outside is undefined (but obviously works). As well as using anything else than _constants_. thanks, -- js suse labs From David.Laight at ACULAB.COM Tue Nov 1 09:39:22 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Tue, 1 Nov 2022 09:39:22 +0000 Subject: [PATCH] wireguard (gcc13): cast enum limits members to int in prints In-Reply-To: <20221031114424.10438-1-jirislaby@kernel.org> References: <20221031114424.10438-1-jirislaby@kernel.org> Message-ID: From: Jiri Slaby (SUSE) > Sent: 31 October 2022 11:44 > > Since gcc13, each member of an enum has the same type as the enum [1]. And > that is inherited from its members. Provided "REKEY_AFTER_MESSAGES = 1ULL > << 60", the named type is unsigned long. > > This generates warnings with gcc-13: > error: format '%d' expects argument of type 'int', but argument 6 has type 'long unsigned int' > > Cast the enum members to int when printing them. > > Alternatively, we can cast it to ulong (to silence gcc < 12) and use %lu. > Alternatively, we can move REKEY_AFTER_MESSAGES away from the enum. I'd suggest moving the 'out of range' value out of the enum. Otherwise integer promotion to 'long' might happen elsewhere and the effects might not be desirable. It is a shame that gcc doesn't force you to add the type to 'big enums' (or emit a warning) so that the behavioural change is properly detected. >From reading the gcc bug it seems that C++ has a syntax for that. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From dxld at darkboxed.org Tue Nov 1 11:07:26 2022 From: dxld at darkboxed.org (dxld at darkboxed.org) Date: Tue, 1 Nov 2022 12:07:26 +0100 Subject: [PATCH v3] wg: Support restricting address family of DNS resolved Endpoint In-Reply-To: <20220822183253.24342-1-dxld@darkboxed.org> References: <20220822183253.24342-1-dxld@darkboxed.org> Message-ID: <20221101110726.h4kamkaiqfl75ccn@House> Hi, Just a ping on this patch. I've actually been able to find a workaround for this issue. We can leave the peer Endpoints empty and use a PostUp action to fill it in like so: PostUp = wg set %i peer $PUBKEY endpoint $(getent ahostsv6 host.example.net | sed -n '/^::ffff:/d;s/\s*DGRAM.*$//p'):51820 PostUp = wg set %i peer $PUBKEY endpoint $(getent ahostsv4 host.example.net | sed -n 's/\s*DGRAM.*$//p'):51820 I use `getent ahosts` since that comes with glibc and is thus available on all my systems as opposed to say `host`. This does have the quirk that for ahostsv6 we need to remove ipv6-mapped-ipv4 addresses with a ::ffff: prefix since getent passes AI_V4MAPPED to getaddrinfo unconditionally, but since it also spits out DGRAM/STREAM/RAW addresses seperatly that's not toooo much uglyness. I'd still like to get the proper solution is, especially since there is no way this workaround will be viable on the mobile apps whereas the AddressFamily= is easy to support there too. --Daniel On Mon, Aug 22, 2022 at 08:32:53PM +0200, Daniel Gr?ber wrote: > When using wireguard tunnels for providing IPv6 connectivity to machines it > can be important to pin which IP address family should be used. > > Consider a peer using a DNS name with both A/AAAA records, wg will > currently blindly follow system policy and use the first address returned > by getaddrinfo(). In typical deployments this will cause the IPv6 address > of the peer to be used, however when the whole IPv6 internet is being > routed over our wireguard all this accomplishes is a traffic black hole. > > Naturally this can be worked around by having different DNS names for > v4-only / dual-stack addresses, however this may not be possible in some > situations where, say, a dynamic-DNS service is also in use. > > To fix this we allow users to control which address family they want using > the new AddressFamily= config option, see wg.8 for details. We also update > reresolve-dns to take the AddressFamily option into account. > > We would like to note that the not_oif patch[1] would also alleviate this > problem but since this never got merged it's not a workable solution. > > [1]: http://marc.info/?t=145452167200014&r=1&w=2 > > Signed-off-by: Daniel Gr?ber > --- > contrib/reresolve-dns/reresolve-dns.sh | 4 ++- > src/config.c | 41 ++++++++++++++++++++------ > src/config.h | 2 +- > src/containers.h | 5 ++++ > src/man/wg.8 | 8 ++++- > src/set.c | 9 +++++- > src/setconf.c | 2 +- > 7 files changed, 57 insertions(+), 14 deletions(-) > > -- > Changes since v1: reword commit message and add missing sign-off. > > diff --git a/contrib/reresolve-dns/reresolve-dns.sh b/contrib/reresolve-dns/reresolve-dns.sh > index 711c332..bdb47ac 100755 > --- a/contrib/reresolve-dns/reresolve-dns.sh > +++ b/contrib/reresolve-dns/reresolve-dns.sh > @@ -17,7 +17,7 @@ process_peer() { > [[ $PEER_SECTION -ne 1 || -z $PUBLIC_KEY || -z $ENDPOINT ]] && return 0 > [[ $(wg show "$INTERFACE" latest-handshakes) =~ ${PUBLIC_KEY//+/\\+}\ ([0-9]+) ]] || return 0 > (( ($EPOCHSECONDS - ${BASH_REMATCH[1]}) > 135 )) || return 0 > - wg set "$INTERFACE" peer "$PUBLIC_KEY" endpoint "$ENDPOINT" > + wg set "$INTERFACE" peer "$PUBLIC_KEY" endpoint "$ENDPOINT" address-family "$FAMILY" > reset_peer_section > } > > @@ -25,6 +25,7 @@ reset_peer_section() { > PEER_SECTION=0 > PUBLIC_KEY="" > ENDPOINT="" > + FAMILY=unspec > } > > reset_peer_section > @@ -38,6 +39,7 @@ while read -r line || [[ -n $line ]]; do > case "$key" in > PublicKey) PUBLIC_KEY="$value"; continue ;; > Endpoint) ENDPOINT="$value"; continue ;; > + AddressFamily) FAMILY="$value"; continue ;; > esac > fi > done < "$CONFIG_FILE" > diff --git a/src/config.c b/src/config.c > index 81ccb47..e8db900 100644 > --- a/src/config.c > +++ b/src/config.c > @@ -192,14 +192,14 @@ static inline int parse_dns_retries(void) > return (int)ret; > } > > -static inline bool parse_endpoint(struct sockaddr *endpoint, const char *value) > +static inline bool parse_endpoint(struct sockaddr *endpoint, const char *value, int family) > { > char *mutable = strdup(value); > char *begin, *end; > int ret, retries = parse_dns_retries(); > struct addrinfo *resolved; > struct addrinfo hints = { > - .ai_family = AF_UNSPEC, > + .ai_family = family, > .ai_socktype = SOCK_DGRAM, > .ai_protocol = IPPROTO_UDP > }; > @@ -279,6 +279,20 @@ static inline bool parse_endpoint(struct sockaddr *endpoint, const char *value) > return true; > } > > +static inline bool parse_address_family(int *family, const char *value) > +{ > + if (strcmp(value, "inet") == 0) > + *family = AF_INET; > + else if (strcmp(value, "inet6") == 0) > + *family = AF_INET6; > + else if (strcmp(value, "unspec") == 0) > + *family = AF_UNSPEC; > + else > + return false; > + > + return true; > +} > + > static inline bool parse_persistent_keepalive(uint16_t *interval, uint32_t *flags, const char *value) > { > unsigned long ret; > @@ -454,8 +468,10 @@ static bool process_line(struct config_ctx *ctx, const char *line) > goto error; > } else if (ctx->is_peer_section) { > if (key_match("Endpoint")) > - ret = parse_endpoint(&ctx->last_peer->endpoint.addr, value); > - else if (key_match("PublicKey")) { > + ctx->last_peer->endpoint_value = strdup(value); > + else if (key_match("AddressFamily")) { > + ret = parse_address_family(&ctx->last_peer->addr_fam, value); > + } else if (key_match("PublicKey")) { > ret = parse_key(ctx->last_peer->public_key, value); > if (ret) > ctx->last_peer->flags |= WGPEER_HAS_PUBLIC_KEY; > @@ -527,19 +543,22 @@ bool config_read_init(struct config_ctx *ctx, bool append) > return true; > } > > -struct wgdevice *config_read_finish(struct config_ctx *ctx) > +struct wgdevice *config_read_finish(struct wgdevice *device) > { > struct wgpeer *peer; > > - for_each_wgpeer(ctx->device, peer) { > + for_each_wgpeer(device, peer) { > if (!(peer->flags & WGPEER_HAS_PUBLIC_KEY)) { > fprintf(stderr, "A peer is missing a public key\n"); > goto err; > } > + > + if (!parse_endpoint(&peer->endpoint.addr, peer->endpoint_value, peer->addr_fam)) > + goto err; > } > - return ctx->device; > + return device; > err: > - free_wgdevice(ctx->device); > + free_wgdevice(device); > return NULL; > } > > @@ -611,7 +630,11 @@ struct wgdevice *config_read_cmd(const char *argv[], int argc) > argv += 1; > argc -= 1; > } else if (!strcmp(argv[0], "endpoint") && argc >= 2 && peer) { > - if (!parse_endpoint(&peer->endpoint.addr, argv[1])) > + peer->endpoint_value = strdup(argv[1]); > + argv += 2; > + argc -= 2; > + } else if (!strcmp(argv[0], "address-family") && argc >= 2 && peer) { > + if (!parse_address_family(&peer->addr_fam, argv[1])) > goto error; > argv += 2; > argc -= 2; > diff --git a/src/config.h b/src/config.h > index 443cf21..6f81da2 100644 > --- a/src/config.h > +++ b/src/config.h > @@ -22,6 +22,6 @@ struct config_ctx { > struct wgdevice *config_read_cmd(const char *argv[], int argc); > bool config_read_init(struct config_ctx *ctx, bool append); > bool config_read_line(struct config_ctx *ctx, const char *line); > -struct wgdevice *config_read_finish(struct config_ctx *ctx); > +struct wgdevice *config_read_finish(struct wgdevice *device); > > #endif > diff --git a/src/containers.h b/src/containers.h > index a82e8dd..c111621 100644 > --- a/src/containers.h > +++ b/src/containers.h > @@ -52,12 +52,15 @@ struct wgpeer { > uint8_t public_key[WG_KEY_LEN]; > uint8_t preshared_key[WG_KEY_LEN]; > > + char *endpoint_value; > union { > struct sockaddr addr; > struct sockaddr_in addr4; > struct sockaddr_in6 addr6; > } endpoint; > > + int addr_fam; > + > struct timespec64 last_handshake_time; > uint64_t rx_bytes, tx_bytes; > uint16_t persistent_keepalive_interval; > @@ -99,6 +102,8 @@ static inline void free_wgdevice(struct wgdevice *dev) > for (struct wgpeer *peer = dev->first_peer, *np = peer ? peer->next_peer : NULL; peer; peer = np, np = peer ? peer->next_peer : NULL) { > for (struct wgallowedip *allowedip = peer->first_allowedip, *na = allowedip ? allowedip->next_allowedip : NULL; allowedip; allowedip = na, na = allowedip ? allowedip->next_allowedip : NULL) > free(allowedip); > + if (peer->endpoint_value) > + free(peer->endpoint_value); > free(peer); > } > free(dev); > diff --git a/src/man/wg.8 b/src/man/wg.8 > index 7984539..fd9fde7 100644 > --- a/src/man/wg.8 > +++ b/src/man/wg.8 > @@ -55,7 +55,7 @@ transfer-rx, transfer-tx, persistent-keepalive. > Shows the current configuration of \fI\fP in the format described > by \fICONFIGURATION FILE FORMAT\fP below. > .TP > -\fBset\fP \fI\fP [\fIlisten-port\fP \fI\fP] [\fIfwmark\fP \fI\fP] [\fIprivate-key\fP \fI\fP] [\fIpeer\fP \fI\fP [\fIremove\fP] [\fIpreshared-key\fP \fI\fP] [\fIendpoint\fP \fI:\fP] [\fIpersistent-keepalive\fP \fI\fP] [\fIallowed-ips\fP \fI/\fP[,\fI/\fP]...] ]... > +\fBset\fP \fI\fP [\fIlisten-port\fP \fI\fP] [\fIfwmark\fP \fI\fP] [\fIprivate-key\fP \fI\fP] [\fIpeer\fP \fI\fP [\fIremove\fP] [\fIpreshared-key\fP \fI\fP] [\fIendpoint\fP \fI:\fP] [\fIaddress-family\fP \fI\fP] [\fIpersistent-keepalive\fP \fI\fP] [\fIallowed-ips\fP \fI/\fP[,\fI/\fP]...] ]... > Sets configuration values for the specified \fI\fP. Multiple > \fIpeer\fPs may be specified, and if the \fIremove\fP argument is given > for a peer, that peer is removed, not configured. If \fIlisten-port\fP > @@ -163,6 +163,12 @@ port number. This endpoint will be updated automatically to the most recent > source IP address and port of correctly authenticated packets from the peer. > Optional. > .IP \(bu > +AddressFamily \(em one of \fIinet\fP, \fIinet6\fP or \fIunspec\fP. When a > +hostname is given for \fIEndpoint\fP, setting this to \fIinet\fP or > +\fIinet6\fP will allow only addresses of the given family to be > +used. Defaults to \fIunspec\fP, which causes the first returned address of > +any type to be used. > +.IP \(bu > PersistentKeepalive \(em a seconds interval, between 1 and 65535 inclusive, of > how often to send an authenticated empty packet to the peer for the purpose of keeping a > stateful firewall or NAT mapping valid persistently. For example, if the interface > diff --git a/src/set.c b/src/set.c > index 75560fd..20ee85e 100644 > --- a/src/set.c > +++ b/src/set.c > @@ -18,13 +18,20 @@ int set_main(int argc, const char *argv[]) > int ret = 1; > > if (argc < 3) { > - fprintf(stderr, "Usage: %s %s [listen-port ] [fwmark ] [private-key ] [peer [remove] [preshared-key ] [endpoint :] [persistent-keepalive ] [allowed-ips /[,/]...] ]...\n", PROG_NAME, argv[0]); > + fprintf(stderr, "Usage: %s %s [listen-port ] [fwmark ] [private-key ] [peer [remove] [preshared-key ] [endpoint :] [address-family ] [persistent-keepalive ] [allowed-ips /[,/]...] ]...\n", PROG_NAME, argv[0]); > return 1; > } > > device = config_read_cmd(argv + 2, argc - 2); > if (!device) > goto cleanup; > + > + device = config_read_finish(device); > + if (!device) { > + fprintf(stderr, "Invalid configuration\n"); > + goto cleanup; > + } > + > strncpy(device->name, argv[1], IFNAMSIZ - 1); > device->name[IFNAMSIZ - 1] = '\0'; > > diff --git a/src/setconf.c b/src/setconf.c > index 1c5b138..c90fd30 100644 > --- a/src/setconf.c > +++ b/src/setconf.c > @@ -127,7 +127,7 @@ int setconf_main(int argc, const char *argv[]) > goto cleanup; > } > } > - device = config_read_finish(&ctx); > + device = config_read_finish(ctx.device); > if (!device) { > fprintf(stderr, "Invalid configuration\n"); > goto cleanup; > -- > 2.30.2 > From kevans at FreeBSD.org Thu Nov 3 18:38:21 2022 From: kevans at FreeBSD.org (kevans at FreeBSD.org) Date: Thu, 3 Nov 2022 13:38:21 -0500 Subject: [PATCH 2/2] ipc: freebsd: NULL out some freed memory in kernel_set_device() In-Reply-To: <20221103183821.48563-1-kevans@FreeBSD.org> References: <20221103183821.48563-1-kevans@FreeBSD.org> Message-ID: <20221103183821.48563-2-kevans@FreeBSD.org> 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, &wgd.wgd_size); nvlist_destroy(nvl_device); + nvl_device = NULL; if (!wgd.wgd_data) goto err; s = get_dgram_socket(); -- 2.36.1 From kevans at FreeBSD.org Thu Nov 3 18:38:20 2022 From: kevans at FreeBSD.org (kevans at FreeBSD.org) Date: Thu, 3 Nov 2022 13:38:20 -0500 Subject: [PATCH 1/2] ipc: freebsd: avoid leaking memory in kernel_get_device() Message-ID: <20221103183821.48563-1-kevans@FreeBSD.org> 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", &size); @@ -184,7 +188,8 @@ static int kernel_get_device(struct wgdevice **device, const char *ifname) aip->family = AF_INET; aip->cidr = number; memcpy(&aip->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", &size); 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(&aip->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 From daryl at isletech.net Fri Nov 4 20:10:31 2022 From: daryl at isletech.net (Daryl Richards) Date: Fri, 4 Nov 2022 16:10:31 -0400 Subject: absolutely terrible wireguard performance on a 4ghz box - need tuning help In-Reply-To: References: Message-ID: 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.. From evrim at core.gen.tr Fri Nov 4 20:55:36 2022 From: evrim at core.gen.tr (Metin Evrim Ulu) Date: Fri, 04 Nov 2022 23:55:36 +0300 Subject: absolutely terrible wireguard performance on a 4ghz box - need tuning help In-Reply-To: References: Message-ID: <871qqiphfk.fsf@core.gen.tr> 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. From clarkcase at gmail.com Sat Nov 5 00:30:25 2022 From: clarkcase at gmail.com (Clark Case) Date: Fri, 4 Nov 2022 20:30:25 -0400 Subject: Windows Client Can't Set MTU Below 1280 Message-ID: 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? From omkhar at gmail.com Sat Nov 5 22:20:01 2022 From: omkhar at gmail.com (Omkhar Arasaratnam) Date: Sat, 5 Nov 2022 18:20:01 -0400 Subject: Wireguard - no logs iOS 16.1 Message-ID: Wireguard 1.0.15 (26) Wireguard Go backend 2ef39d47 I am unable to view logs. Clicking on the view log button momentarily renders text, then it goes blank. Tried this on two different phones (iPhone 11 pro max, iPhone 13 Pro) --oa From syzbot+a70a6358abd2c3f9550f at syzkaller.appspotmail.com Tue Nov 8 13:40:42 2022 From: syzbot+a70a6358abd2c3f9550f at syzkaller.appspotmail.com (syzbot) Date: Tue, 08 Nov 2022 05:40:42 -0800 Subject: [syzbot] BUG: MAX_LOCKDEP_KEYS too low! (2) In-Reply-To: <0000000000003687bd05c2b2401d@google.com> Message-ID: <000000000000b4dae405ecf5af7f@google.com> syzbot has found a reproducer for the following issue on: HEAD commit: 3577a7611842 Merge branches 'for-next/acpi', 'for-next/kbu.. git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci console output: https://syzkaller.appspot.com/x/log.txt?x=15ea3e61880000 kernel config: https://syzkaller.appspot.com/x/.config?x=606e57fd25c5c6cc dashboard link: https://syzkaller.appspot.com/bug?extid=a70a6358abd2c3f9550f compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2 userspace arch: arm64 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=168c4c99880000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=145d6376880000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/054b1f56af52/disk-3577a761.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/c616835b2a22/vmlinux-3577a761.xz kernel image: https://storage.googleapis.com/syzbot-assets/9825c28b2090/Image-3577a761.gz.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+a70a6358abd2c3f9550f at syzkaller.appspotmail.com netlink: 4 bytes leftover after parsing attributes in process `syz-executor357'. device team6635 entered promiscuous mode 8021q: adding VLAN 0 to HW filter on device team6635 BUG: MAX_LOCKDEP_KEYS too low! turning off the locking correctness validator. CPU: 0 PID: 9692 Comm: syz-executor357 Not tainted 6.1.0-rc4-syzkaller-31844-g3577a7611842 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/30/2022 Call trace: dump_backtrace+0x1c4/0x1f0 arch/arm64/kernel/stacktrace.c:156 show_stack+0x2c/0x54 arch/arm64/kernel/stacktrace.c:163 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x104/0x16c lib/dump_stack.c:106 dump_stack+0x1c/0x58 lib/dump_stack.c:113 register_lock_class+0x2e4/0x2f8 kernel/locking/lockdep.c:1326 __lock_acquire+0xa8/0x3084 kernel/locking/lockdep.c:4934 lock_acquire+0x100/0x1f8 kernel/locking/lockdep.c:5668 __mutex_lock_common+0xd4/0xca8 kernel/locking/mutex.c:603 __mutex_lock kernel/locking/mutex.c:747 [inline] mutex_lock_nested+0x38/0x44 kernel/locking/mutex.c:799 team_vlan_rx_add_vid+0x38/0xd8 drivers/net/team/team.c:1904 vlan_add_rx_filter_info net/8021q/vlan_core.c:211 [inline] __vlan_vid_add net/8021q/vlan_core.c:306 [inline] vlan_vid_add+0x328/0x38c net/8021q/vlan_core.c:336 vlan_device_event+0x200/0xc4c net/8021q/vlan.c:385 notifier_call_chain kernel/notifier.c:87 [inline] raw_notifier_call_chain+0x7c/0x108 kernel/notifier.c:455 __dev_notify_flags+0x170/0x2e8 rtnl_newlink_create+0x460/0x6bc net/core/rtnetlink.c:3372 __rtnl_newlink net/core/rtnetlink.c:3581 [inline] rtnl_newlink+0x728/0xa04 net/core/rtnetlink.c:3594 rtnetlink_rcv_msg+0x484/0x82c net/core/rtnetlink.c:6091 netlink_rcv_skb+0xe8/0x1d4 net/netlink/af_netlink.c:2540 rtnetlink_rcv+0x28/0x38 net/core/rtnetlink.c:6109 netlink_unicast_kernel+0xfc/0x1dc net/netlink/af_netlink.c:1319 netlink_unicast+0x164/0x248 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x484/0x584 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0x2f8/0x440 net/socket.c:2482 ___sys_sendmsg net/socket.c:2536 [inline] __sys_sendmsg+0x1ac/0x228 net/socket.c:2565 __do_sys_sendmsg net/socket.c:2574 [inline] __se_sys_sendmsg net/socket.c:2572 [inline] __arm64_sys_sendmsg+0x2c/0x3c net/socket.c:2572 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall arch/arm64/kernel/syscall.c:52 [inline] el0_svc_common+0x138/0x220 arch/arm64/kernel/syscall.c:142 do_el0_svc+0x48/0x164 arch/arm64/kernel/syscall.c:206 el0_svc+0x58/0x150 arch/arm64/kernel/entry-common.c:637 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655 el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:581 From dvyukov at google.com Tue Nov 8 18:36:32 2022 From: dvyukov at google.com (Dmitry Vyukov) Date: Tue, 8 Nov 2022 10:36:32 -0800 Subject: [syzbot] BUG: MAX_LOCKDEP_KEYS too low! (2) In-Reply-To: <000000000000b4dae405ecf5af7f@google.com> References: <0000000000003687bd05c2b2401d@google.com> <000000000000b4dae405ecf5af7f@google.com> Message-ID: On Tue, 8 Nov 2022 at 05:40, syzbot wrote: > > syzbot has found a reproducer for the following issue on: > > HEAD commit: 3577a7611842 Merge branches 'for-next/acpi', 'for-next/kbu.. > git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci > console output: https://syzkaller.appspot.com/x/log.txt?x=15ea3e61880000 > kernel config: https://syzkaller.appspot.com/x/.config?x=606e57fd25c5c6cc > dashboard link: https://syzkaller.appspot.com/bug?extid=a70a6358abd2c3f9550f > compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2 > userspace arch: arm64 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=168c4c99880000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=145d6376880000 > > Downloadable assets: > disk image: https://storage.googleapis.com/syzbot-assets/054b1f56af52/disk-3577a761.raw.xz > vmlinux: https://storage.googleapis.com/syzbot-assets/c616835b2a22/vmlinux-3577a761.xz > kernel image: https://storage.googleapis.com/syzbot-assets/9825c28b2090/Image-3577a761.gz.xz > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+a70a6358abd2c3f9550f at syzkaller.appspotmail.com I see team device code uses lockdep_register_key()/lockdep_set_class() in some interesting ways: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/tree/drivers/net/team/team.c?id=3577a76118426e4409ecf4f75520925eff67d42c#n1657 https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/tree/drivers/net/team/team.c?id=3577a76118426e4409ecf4f75520925eff67d42c#n2008 I guess that's what causes lockdep capacity exhaustion. Does team use it incorrectly? > netlink: 4 bytes leftover after parsing attributes in process `syz-executor357'. > device team6635 entered promiscuous mode > 8021q: adding VLAN 0 to HW filter on device team6635 > BUG: MAX_LOCKDEP_KEYS too low! > turning off the locking correctness validator. > CPU: 0 PID: 9692 Comm: syz-executor357 Not tainted 6.1.0-rc4-syzkaller-31844-g3577a7611842 #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/30/2022 > Call trace: > dump_backtrace+0x1c4/0x1f0 arch/arm64/kernel/stacktrace.c:156 > show_stack+0x2c/0x54 arch/arm64/kernel/stacktrace.c:163 > __dump_stack lib/dump_stack.c:88 [inline] > dump_stack_lvl+0x104/0x16c lib/dump_stack.c:106 > dump_stack+0x1c/0x58 lib/dump_stack.c:113 > register_lock_class+0x2e4/0x2f8 kernel/locking/lockdep.c:1326 > __lock_acquire+0xa8/0x3084 kernel/locking/lockdep.c:4934 > lock_acquire+0x100/0x1f8 kernel/locking/lockdep.c:5668 > __mutex_lock_common+0xd4/0xca8 kernel/locking/mutex.c:603 > __mutex_lock kernel/locking/mutex.c:747 [inline] > mutex_lock_nested+0x38/0x44 kernel/locking/mutex.c:799 > team_vlan_rx_add_vid+0x38/0xd8 drivers/net/team/team.c:1904 > vlan_add_rx_filter_info net/8021q/vlan_core.c:211 [inline] > __vlan_vid_add net/8021q/vlan_core.c:306 [inline] > vlan_vid_add+0x328/0x38c net/8021q/vlan_core.c:336 > vlan_device_event+0x200/0xc4c net/8021q/vlan.c:385 > notifier_call_chain kernel/notifier.c:87 [inline] > raw_notifier_call_chain+0x7c/0x108 kernel/notifier.c:455 > __dev_notify_flags+0x170/0x2e8 > rtnl_newlink_create+0x460/0x6bc net/core/rtnetlink.c:3372 > __rtnl_newlink net/core/rtnetlink.c:3581 [inline] > rtnl_newlink+0x728/0xa04 net/core/rtnetlink.c:3594 > rtnetlink_rcv_msg+0x484/0x82c net/core/rtnetlink.c:6091 > netlink_rcv_skb+0xe8/0x1d4 net/netlink/af_netlink.c:2540 > rtnetlink_rcv+0x28/0x38 net/core/rtnetlink.c:6109 > netlink_unicast_kernel+0xfc/0x1dc net/netlink/af_netlink.c:1319 > netlink_unicast+0x164/0x248 net/netlink/af_netlink.c:1345 > netlink_sendmsg+0x484/0x584 net/netlink/af_netlink.c:1921 > sock_sendmsg_nosec net/socket.c:714 [inline] > sock_sendmsg net/socket.c:734 [inline] > ____sys_sendmsg+0x2f8/0x440 net/socket.c:2482 > ___sys_sendmsg net/socket.c:2536 [inline] > __sys_sendmsg+0x1ac/0x228 net/socket.c:2565 > __do_sys_sendmsg net/socket.c:2574 [inline] > __se_sys_sendmsg net/socket.c:2572 [inline] > __arm64_sys_sendmsg+0x2c/0x3c net/socket.c:2572 > __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] > invoke_syscall arch/arm64/kernel/syscall.c:52 [inline] > el0_svc_common+0x138/0x220 arch/arm64/kernel/syscall.c:142 > do_el0_svc+0x48/0x164 arch/arm64/kernel/syscall.c:206 > el0_svc+0x58/0x150 arch/arm64/kernel/entry-common.c:637 > el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655 > el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:581 > From pperry at elrepo.org Thu Nov 10 20:41:20 2022 From: pperry at elrepo.org (Phil Perry) Date: Thu, 10 Nov 2022 20:41:20 +0000 Subject: compat: update for RHEL 8.7 Message-ID: <306f35dc-5101-35f0-a466-ee5cee758d07@elrepo.org> Update for release of RHEL 8.7, which now backports ktime_get_coarse_boottime_ns() Signed-off-by: Philip J. Perry diff -Naurp wireguard-linux-compat-1.0.20220627.orig/src/compat/compat.h wireguard-linux-compat-1.0.20220627/src/compat/compat.h --- a/src/compat/compat.h 2022-06-27 11:54:37.000000000 +0100 +++ b/src/compat/compat.h 2022-11-10 19:55:49.653581044 +0000 @@ -16,7 +16,7 @@ #define ISRHEL7 #elif RHEL_MAJOR == 8 #define ISRHEL8 -#if RHEL_MINOR >= 6 +#if RHEL_MINOR >= 7 #define ISCENTOS8S #endif #endif @@ -412,6 +412,7 @@ static inline u64 __compat_jiffies64_to_ } #define jiffies64_to_nsecs __compat_jiffies64_to_nsecs #endif +#if !defined(ISRHEL8) static inline u64 ktime_get_coarse_boottime_ns(void) { #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0) @@ -423,6 +424,7 @@ static inline u64 ktime_get_coarse_boott #endif } #endif +#endif #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 14, 0) #include From dxld at darkboxed.org Sun Nov 20 22:46:01 2022 From: dxld at darkboxed.org (=?UTF-8?q?Daniel=20Gr=C3=B6ber?=) Date: Sun, 20 Nov 2022 23:46:01 +0100 Subject: [PATCH] wg: Allow config to read private key from file Message-ID: <20221120224601.77300-1-dxld@darkboxed.org> This adds a new config key PrivateKeyFile= that simply hooks up the existing code for the `wg set ... private-key /file` codepath. Using this new option the interface configs can be much easier to deploy in an automated fashion as they don't contain secrets anymore. The private key can easily be provisioned out of band or using a one-time provisioning step instead. Before this patch we were using a neat hack: it's possible to simply omit PrivateKey= and set it using PostUp= wg set %i private-key /some/file. However this breaks when we try to use setconf or synconf as they will (rightly) unset the private key instead of leaving it as-is. --- src/config.c | 4 ++++ src/man/wg.8 | 2 ++ 2 files changed, 6 insertions(+) diff --git a/src/config.c b/src/config.c index e8db900..49cbb07 100644 --- a/src/config.c +++ b/src/config.c @@ -464,6 +464,10 @@ static bool process_line(struct config_ctx *ctx, const char *line) ret = parse_key(ctx->device->private_key, value); if (ret) ctx->device->flags |= WGDEVICE_HAS_PRIVATE_KEY; + } else if (key_match("PrivateKeyFile")) { + ret = parse_keyfile(ctx->device->private_key, value); + if (ret) + ctx->device->flags |= WGDEVICE_HAS_PRIVATE_KEY; } else goto error; } else if (ctx->is_peer_section) { diff --git a/src/man/wg.8 b/src/man/wg.8 index fd9fde7..1d37338 100644 --- a/src/man/wg.8 +++ b/src/man/wg.8 @@ -134,6 +134,8 @@ The \fIInterface\fP section may contain the following fields: .IP \(bu PrivateKey \(em a base64 private key generated by \fIwg genkey\fP. Required. .IP \(bu +PrivateKeyFile \(em path to a file containing base64 private key. May be used instead of \fIPrivateKey\fP. Optional. +.IP \(bu ListenPort \(em a 16-bit port for listening. Optional; if not specified, chosen randomly. .IP \(bu -- 2.30.2 From mjt at tls.msk.ru Mon Nov 21 06:31:41 2022 From: mjt at tls.msk.ru (Michael Tokarev) Date: Mon, 21 Nov 2022 09:31:41 +0300 Subject: [PATCH] wg: Allow config to read private key from file In-Reply-To: <20221120224601.77300-1-dxld@darkboxed.org> References: <20221120224601.77300-1-dxld@darkboxed.org> Message-ID: 21.11.2022 01:46, Daniel Gr?ber wrote: > This adds a new config key PrivateKeyFile= that simply hooks up the > existing code for the `wg set ... private-key /file` codepath. > > Using this new option the interface configs can be much easier to deploy in > an automated fashion as they don't contain secrets anymore. The private key > can easily be provisioned out of band or using a one-time provisioning step > instead. This is definitely a very welcome option in my PoV. Add my Signed-off-by: Michael Tokarev for this. > Before this patch we were using a neat hack: it's possible to simply omit > PrivateKey= and set it using PostUp= wg set %i private-key /some/file. Well, this isn't really neat, it is a hackish workaround for the missing functionality ;) On a side, note, almost a year ago I sent a patch for wg utility to recognize and discard some keywords which are processed by wg-quick script - like, Address=. This way, there's no need to pre-process the config file anymore, and in order to recognize more peers, one doesn't have to restart the tunnel interface, instead, a regular wg syncconf wgif.conf is sufficient, and many things can be simplified too (removing the preprocessing). I've never got any reply for these patches. /mjt From dxld at darkboxed.org Mon Nov 21 13:28:55 2022 From: dxld at darkboxed.org (dxld at darkboxed.org) Date: Mon, 21 Nov 2022 14:28:55 +0100 Subject: [PATCH] wg: Allow config to read private key from file In-Reply-To: References: <20221120224601.77300-1-dxld@darkboxed.org> Message-ID: <20221121132855.vkwsez6kjm3ughrr@House.clients.dxld.at> Hi Michael, On Mon, Nov 21, 2022 at 09:31:41AM +0300, Michael Tokarev wrote: > 21.11.2022 01:46, Daniel Gr?ber wrote: > > Using this new option the interface configs can be much easier to deploy in > > an automated fashion as they don't contain secrets anymore. The private key > > can easily be provisioned out of band or using a one-time provisioning step > > instead. > > This is definitely a very welcome option in my PoV. > > Add my > Signed-off-by: Michael Tokarev I think you mean Reviewed-By? Speaking of which I actually forgot the signoff myself. Doh. Is Reviewed-By something we do here? I can't find a single such tag with `git log --grep Reviewed-By`. I appreciate the positive response nontheless though :) > > Before this patch we were using a neat hack: it's possible to simply omit > > PrivateKey= and set it using PostUp= wg set %i private-key /some/file. > > Well, this isn't really neat, it is a hackish workaround for the missing > functionality ;) It does work surprisingly well though :D. I just re-set the private-key after syncconf now, which definetly ought to loose some traffic but it works at least ;) > On a side, note, almost a year ago I sent a patch for wg utility to recognize > and discard some keywords which are processed by wg-quick script - like, > Address=. This way, there's no need to pre-process the config file anymore, > and in order to recognize more peers, one doesn't have to restart the > tunnel interface, instead, a regular wg syncconf wgif.conf is sufficient, > and many things can be simplified too (removing the preprocessing). Ok I think I found your patch[1]. So we did actually independently come up with the idea of PrivateKeyFile, interesting. Also you support PresharedKey too. I realised I forgot that one right after sending the patch obv. ;) I'll send a v2 for that soon. [1]: https://lists.zx2c4.com/pipermail/wireguard/2021-January/006346.html As for ignoring the wg-quick options, I'm not sure what's the right way to go there. I don't find the wg-quick strip approach toooo taxing but it sure would be more convenient to just call one tool. > I've never got any reply for these patches. I have another patch pending for a longish while aswell "wg: Support restricting address family of DNS resolved Endpoint". IMO you should have just resent your series every couple of months :) --Daniel From ulli at noc23.de Mon Nov 28 17:56:02 2022 From: ulli at noc23.de (Ulrich Kalloch) Date: Mon, 28 Nov 2022 18:56:02 +0100 Subject: Wireguard - no logs iOS 16.1 In-Reply-To: References: Message-ID: <15709745-61e4-5aef-200d-4e3802718c7b@noc23.de> Am 05.11.22 um 23:20 schrieb Omkhar Arasaratnam: > Wireguard 1.0.15 (26) > Wireguard Go backend 2ef39d47 > > I am unable to view logs. Clicking on the view log button momentarily > renders text, then it goes blank. Tried this on two different phones > (iPhone 11 pro max, iPhone 13 Pro) > > --oa Same here. But Save and Read in Notes Works. Best -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x44BE4EB74E7625C8.asc Type: application/pgp-keys Size: 3935 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From hello at danielcolquitt.com Sun Nov 6 11:52:52 2022 From: hello at danielcolquitt.com (Daniel Colquitt) Date: Sun, 06 Nov 2022 11:52:52 -0000 Subject: Wireguard - no logs iOS 16.1 In-Reply-To: References: Message-ID: <6A111D04-984C-45A7-85A0-A4E2556E42F2@danielcolquitt.com> I have reproduced the issue on iPhone 13. Also occurred on iOS 16.0 -D > On 5 Nov 2022, at 22:20, Omkhar Arasaratnam wrote: > > ?Wireguard 1.0.15 (26) > Wireguard Go backend 2ef39d47 > > I am unable to view logs. Clicking on the view log button momentarily > renders text, then it goes blank. Tried this on two different phones > (iPhone 11 pro max, iPhone 13 Pro) > > --oa From schveiguy at gmail.com Wed Nov 16 16:52:41 2022 From: schveiguy at gmail.com (Steven Schveighoffer) Date: Wed, 16 Nov 2022 11:52:41 -0500 Subject: M1 Mac with OSX 12.6 wifi dropouts Message-ID: <500E3D1A-A1C7-4084-90D4-CE5AD467A7A2@gmail.com> Not sure if this is the right place to ask about it. But I have been using wireguard recently, and I have noticed that when I enable the VPN, my wifi signal immediately goes down 1 bar. Also, after some time of using it, the wifi will experience periodic dropouts (on the order of every 10 minutes to 2 hours) I?m clueless as to how wireguard can be causing this, but I found this situation by rebooting into safe mode, noting that the wifi did not have any problems, and then starting up wireguard to see the drop occur. I?m noticing that WG for mac hasn?t been updated for 1 year. Does anyone else experience this issue, or know of its cause? Will also agree that it?s possible WG isn?t the culprit, but I?m having a hard time narrowing it down. If anyone has experience in how to find what causes this, please let me know. -Steve From ondrej.grover at gmail.com Thu Nov 24 10:03:14 2022 From: ondrej.grover at gmail.com (=?UTF-8?Q?Ond=C5=99ej_Grover?=) Date: Thu, 24 Nov 2022 11:03:14 +0100 Subject: DNS endpoint resolution in container namespace Message-ID: Hi, I tried to follow the example here https://www.wireguard.com/netns/#ordinary-containerization but I found out that the DNS endpoint resolution through ip netns exec container wg setconf wg0 /etc/wireguard/wg0.conf won't work, because it is run in the new container namespace not yet capable of DNS resolution. Looking at the source code here https://git.zx2c4.com/wireguard-tools/tree/src/config.c#n242 confirmed my suspicion that the DNS resolution is done by the wg tool in the container namespace rather than in the original namespace. In an ideal world the DNS resolution should IMHO happen in the original namespace capable of DNS resolution where the world-facing UDP socket using that endpoint IP is anyway. Often one could use just a hard-coded IP (that's indeed what I resorted to in the end, or perform DNS resolution at container provisioning time as suggested by mrngm in IRC) for the wg0.conf in the container, but with DynDNS and similar setups this may not be possible. But since that might require significant changes (e.g. requesting DNS resolution in the original namespace through the kernel?), perhaps at least in the short term I would recommend that this caveat is mentioned on the webpage and/or perhaps in the example the `wg setconf` step would be run in the original namespace (unless there is some repercussion to that I did not consider). Best wishes and thanks for all your work making wireguard what it is today, Ondrej G. From omkhar at gmail.com Tue Nov 29 01:53:38 2022 From: omkhar at gmail.com (Omkhar Arasaratnam) Date: Mon, 28 Nov 2022 20:53:38 -0500 Subject: Wireguard - no logs iOS 16.1 In-Reply-To: <15709745-61e4-5aef-200d-4e3802718c7b@noc23.de> References: <15709745-61e4-5aef-200d-4e3802718c7b@noc23.de> Message-ID: Agreed, Save and Read do work. --oa On Mon, Nov 28, 2022 at 12:59 PM Ulrich Kalloch wrote: > > Am 05.11.22 um 23:20 schrieb Omkhar Arasaratnam: > > Wireguard 1.0.15 (26) > > Wireguard Go backend 2ef39d47 > > > > I am unable to view logs. Clicking on the view log button momentarily > > renders text, then it goes blank. Tried this on two different phones > > (iPhone 11 pro max, iPhone 13 Pro) > > > > --oa > > Same here. > > But Save and Read in Notes Works. > > Best