From nico.schottelius at ungleich.ch Thu May 5 19:32:19 2022 From: nico.schottelius at ungleich.ch (Nico Schottelius) Date: Thu, 05 May 2022 21:32:19 +0200 Subject: Interface not deleted in kubernetes Message-ID: <874k2393cx.fsf@ungleich.ch> Hello, I am not sure if I am off-topic here, but I am not sure where to best raise this issue. The situation is: if I start a Pod in Kubernetes that uses the ungleich-wireguard:0.0.5 [0] container, which is basically using this script [1] I am able to get the following output: -------------------------------------------------------------------------------- [21:29] blind:~% kubectl -n test logs -f wireguard-7cf446469-gmkvd + wg show interface: clients public key: 5QzByP8MnQyR7seJWJyiP6fFHn5OnkPI+O0WAuYoLko= private key: (hidden) listening port: 51820 peer: fnIGys3sZKfyjSA7oXw891IOxuuRi7yYM6tihNG+1WA= allowed ips: 10.0.0.2/32 + wg-quick up /etc/wireguard/clients.conf Warning: `/etc/wireguard/..2022_05_05_19_29_32.4005058985/clients.conf' is world accessible wg-quick: `clients' already exists + exit 1 [21:29] blind:~% -------------------------------------------------------------------------------- As the pod/container are freshly created, I assume that the "clients" interface is a leftover from a previous run of that container. Which brings me to the real questions: Are wireguard interfaces a) Not contained in a container? b) Not destroyed if the container is destroyed? As containers are namespaced, I would have expected the device to die with the container, but I even cleared the full deployment and get this error again. My logical understand would be that the interface should be destroyed if the container exits, however the output implies that this is not the case. Any pointers in this direction are very welcome. Best regards, Nico [0] https://hub.docker.com/layers/ungleich-wireguard/ungleich/ungleich-wireguard/0.0.5/images/sha256-cf50085115df1f686509288375349ce61cc4ef06a06c940cf7cbd9041a6d9ef6?context=explore [1] -------------------------------------------------------------------------------- #!/bin/sh set -x # Ensure everything is clean / show prior state wg show # Start all definitions for conf in /etc/wireguard/*.conf; do # Try to up and if any tunnel fails -> exit wg-quick up "$conf" || exit 1 done # Debug output while true; do wg show sleep 300 done -------------------------------------------------------------------------------- -- Sustainable and modern Infrastructures by ungleich.ch From nico.schottelius at ungleich.ch Thu May 5 20:01:24 2022 From: nico.schottelius at ungleich.ch (Nico Schottelius) Date: Thu, 05 May 2022 22:01:24 +0200 Subject: Why is the src_valid_mark needed and not allowed (in kubernetes)? Message-ID: <87o80b7mzf.fsf@ungleich.ch> Hello again, while debugging wireguard in Kubernetes, we noticed that adding a default route for IPv4 is not possible/allowed, wg-quick fails with: sysctl: error setting key 'net.ipv4.conf.all.src_valid_mark': Read-only file system Which can be traced back to: [[ $proto == -4 ]] && cmd sysctl -q net.ipv4.conf.all.src_valid_mark=1 inside the add_default() { function of wg-quick. If one tries to escape this using a pod specification to set the sysctl using spec: securityContext: sysctls: - name: net.ipv4.conf.all.src_valid_mark value: "1" Kubernetes by default disallows it and returns a "SysctlForbidden" error. Now, one can easily "fool" wg-quick using AllowedIPs = 0.0.0.0/1, 128.0.0.0/1 instead of AllowedIPs = 0.0.0.0/0 which makes the container work w/o the sysctl, as the add_default() function is not called. Running it like this in kubernetes results in: + wg show interface: ipv4 public key: HV9IgFLPSHJgG4jbDzaJg97Uch3eebrV5we4wUkAcUg= private key: (hidden) listening port: 51828 peer: 6BRnQ+dmeFzVCH9RbM1pbJ7u3y3qrl+zUzzYCmC88kE= endpoint: [2a0a:e5c0:2:2:0:84ff:fe41:f265]:51820 allowed ips: 0.0.0.0/1, 128.0.0.0/1 And allows outside IPv4 communication within an IPv6 only kubernetes cluster, which was the objective in the first place. My questions: - Why is net.ipv4.conf.all.src_valid_mark needed? - And why does working around using 0.0.0.0/1, 128.0.0.0/1 works / what is the drawback of this? Best regards and a good evening from container land, Nico -- Sustainable and modern Infrastructures by ungleich.ch From nico.schottelius at ungleich.ch Sun May 8 06:34:46 2022 From: nico.schottelius at ungleich.ch (Nico Schottelius) Date: Sun, 08 May 2022 08:34:46 +0200 Subject: Outgoing ping required in container environment (even with PersistentKeepalive) Message-ID: <878rrcfrpv.fsf@ungleich.ch> Good morning, another day news from the container land. When running wireguard in kubernetes, deleting the existing pod and replacing it with a new one, I see the following behaviour: - The assigned IPv4 address stops being reachable (good so far) - The assigned IPv4 address is then shortly reachable for about 5 seconds - The assigned IPv4 address stops being reachable (not good) - The assigned IPv4 address is again reachable, if I trigger a ping through the tunnel inside the container (ok, but why?) I am using the following configuration: -------------------------------------------------------------------------------- [Interface] PrivateKey = ... ListenPort = 51828 Address = 185.155.29.81/32 PostUp = iptables -t nat -I POSTROUTING -o ipv4 -j MASQUERADE # upstream [Peer] Endpoint = vpn-...:51820 PublicKey = 6BRnQ+dmeFzVCH9RbM1pbJ7u3y3qrl+zUzzYCmC88kE= AllowedIPs = 0.0.0.0/1, 128.0.0.0/1 PersistentKeepalive = 25 -------------------------------------------------------------------------------- And the following container specification: -------------------------------------------------------------------------------- spec: containers: - name: wireguard image: ungleich/ungleich-wireguard:{{ $.Chart.AppVersion }} # We only support 1 listener at the moment # Outgoing connections are not affected ports: - containerPort: 51820 securityContext: capabilities: # NET_ADMIN for wg # NET_RAW for iptables add: ["NET_ADMIN", "NET_RAW" ] volumeMounts: - name: wireguard-config mountPath: "/etc/wireguard" resources: requests: memory: {{ $v.memory | default "1Gi" }} cpu: {{ $v.cpu | default "1000m" }} limits: memory: {{ $v.memory | default "1Gi" }} cpu: {{ $v.cpu | default "1000m" }} -------------------------------------------------------------------------------- The strange thing is that after issuing the ping once inside the container: -------------------------------------------------------------------------------- [8:41] nb2:~% kubectl -n wireguard exec -ti wireguard-vpn-server-7db664db6f-zl4fz -- ping -c2 -4 google.com PING google.com (172.217.168.78): 56 data bytes 64 bytes from 172.217.168.78: seq=0 ttl=116 time=9.110 ms 64 bytes from 172.217.168.78: seq=1 ttl=116 time=6.664 ms --- google.com ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 6.664/7.887/9.110 ms -------------------------------------------------------------------------------- The connection stays correctly established. If anyone has a pointer on what might be going on, any help is appreciated. Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch From nico.schottelius at ungleich.ch Sun May 8 19:53:21 2022 From: nico.schottelius at ungleich.ch (Nico Schottelius) Date: Sun, 08 May 2022 21:53:21 +0200 Subject: Outgoing ping required in container environment (even with PersistentKeepalive) In-Reply-To: <878rrcfrpv.fsf@ungleich.ch> References: <878rrcfrpv.fsf@ungleich.ch> Message-ID: <87mtfrlrww.fsf@ungleich.ch> A follow up: we "upgraded" the wireguard container to use the following entrypoint.sh instead: -------------------------------------------------------------------------------- set -x # Ensure everything is clean / show prior state wg show # Start all definitions for conf in /etc/wireguard/*.conf; do # Remove leftovers?? wg-quick down $conf # Try to up and if any tunnel fails -> exit wg-quick up "$conf" || (sleep 300; exit 1) done # Debug output while true; do # Establish tunnels, keepalive alone is not enough for some reason ping -c2 185.203.112.1 ping -c2 2a0a:e5c0:: wg show sleep 300 done -------------------------------------------------------------------------------- This establishes the connection reliably. I guess that should not be the case, but effectively, it is. I was for a moment suspecting that the old container is overlapping running while the new one is created and whether there is a race condition, however two points speak against that being the source of the problem: - Using the "Recreate strategy" in k8s, the container is first shut down. Using this, the behaviour does not change - Even if my assumption was right, I'd expect a new handshake at some point to happen, but even minutes after restarting the container, the IPv4 address is not reachable. Best regards, Nico Nico Schottelius writes: > Good morning, > > another day news from the container land. When running wireguard in > kubernetes, deleting the existing pod and replacing it with a new one, I > see the following behaviour: > > - The assigned IPv4 address stops being reachable (good so far) > - The assigned IPv4 address is then shortly reachable for about 5 seconds > - The assigned IPv4 address stops being reachable (not good) > - The assigned IPv4 address is again reachable, if I trigger a ping > through the tunnel inside the container (ok, but why?) > > I am using the following configuration: > > -------------------------------------------------------------------------------- > [Interface] > PrivateKey = ... > ListenPort = 51828 > Address = 185.155.29.81/32 > PostUp = iptables -t nat -I POSTROUTING -o ipv4 -j MASQUERADE > > # upstream > [Peer] > Endpoint = vpn-...:51820 > PublicKey = 6BRnQ+dmeFzVCH9RbM1pbJ7u3y3qrl+zUzzYCmC88kE= > AllowedIPs = 0.0.0.0/1, 128.0.0.0/1 > PersistentKeepalive = 25 > -------------------------------------------------------------------------------- > > And the following container specification: > > -------------------------------------------------------------------------------- > spec: > containers: > - name: wireguard > image: ungleich/ungleich-wireguard:{{ $.Chart.AppVersion }} > # We only support 1 listener at the moment > # Outgoing connections are not affected > ports: > - containerPort: 51820 > securityContext: > capabilities: > # NET_ADMIN for wg > # NET_RAW for iptables > add: ["NET_ADMIN", "NET_RAW" ] > volumeMounts: > - name: wireguard-config > mountPath: "/etc/wireguard" > resources: > requests: > memory: {{ $v.memory | default "1Gi" }} > cpu: {{ $v.cpu | default "1000m" }} > limits: > memory: {{ $v.memory | default "1Gi" }} > cpu: {{ $v.cpu | default "1000m" }} > -------------------------------------------------------------------------------- > > The strange thing is that after issuing the ping once inside the > container: > > -------------------------------------------------------------------------------- > [8:41] nb2:~% kubectl -n wireguard exec -ti wireguard-vpn-server-7db664db6f-zl4fz -- ping -c2 -4 google.com > PING google.com (172.217.168.78): 56 data bytes > 64 bytes from 172.217.168.78: seq=0 ttl=116 time=9.110 ms > 64 bytes from 172.217.168.78: seq=1 ttl=116 time=6.664 ms > > --- google.com ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max = 6.664/7.887/9.110 ms > -------------------------------------------------------------------------------- > > The connection stays correctly established. > > If anyone has a pointer on what might be going on, any help is > appreciated. > > Best regards, > > Nico -- Sustainable and modern Infrastructures by ungleich.ch From rm at romanrm.net Sun May 8 20:09:19 2022 From: rm at romanrm.net (Roman Mamedov) Date: Mon, 9 May 2022 01:09:19 +0500 Subject: Outgoing ping required in container environment (even with PersistentKeepalive) In-Reply-To: <878rrcfrpv.fsf@ungleich.ch> References: <878rrcfrpv.fsf@ungleich.ch> Message-ID: <20220509010919.390ea1d8@nvm> On Sun, 08 May 2022 08:34:46 +0200 Nico Schottelius wrote: > The connection stays correctly established. > > If anyone has a pointer on what might be going on, any help is > appreciated. Maybe you don't have a corresponding firewall rule, and happen to rely on the ESTABLISHED,RELATED matching instead? This could explain the "works after a ping" behaviour. But then the PersistentKeepalive could be expected to help as well. -- With respect, Roman From felix.geschwindner at icloud.com Tue May 3 16:37:43 2022 From: felix.geschwindner at icloud.com (Felix Geschwindner) Date: Tue, 3 May 2022 09:37:43 -0700 Subject: WireGuard Windows client unable to establish connections Message-ID: <7E1C5927-EB3F-4F7A-AA4E-6A1D38A8772D@icloud.com> Hey folks, I?ve been using WireGuard on my macOS, Linux & Windows machines for a while now and recently the Windows machines started to block WireGuard in a strange way. I?m using Windows 10 & 11 with the latest updates. WireGuard client version is v0.5.3. The config looks like this: [Interface] PrivateKey = Address = 10.0.0.10/32 DNS = 192.168.0.1 [Peer] PublicKey = AllowedIPs = 192.168.0.0/24 Endpoint = vpn.example.com:51820 When I activate the WireGuard VPN it reports that the connection is active and ready to go. I even see the new adapter created in the Windows network settings but when I try to ping resources behind the VPN, I get a ?General Failure? message from the command line. Pinging the local client VPN adapter IP works. First I tried a couple simple things that may help the WireGuard client to succeed: ? Reboot ? Run as administrator ? Re-install client ? Re-generate keys & config ? Try same config on a Mac to rule out mismatches (this works) ? Run WireGuard in Windows 7 compatibility mode ? Configure the TCP/IP stack in the registry to favor IPv4 over IPv6 ? Disable IPv6 entirely ? Add explicit firewall rule to allow WireGuard ports ? Disable firewall entirely ? Try full-tunnel via 0.0.0.0/0 in "AllowedIPs" None of the above points produced any change whatsoever. Finally I took to WireShark to see if it can help me identify where the packets get stuck and surprisingly WireShark doesn?t show ANY packets destined for the 51820 UDP port on ANY interface. Which is the point at which I ran out of ideas. I tried this on 2 different Windows machines and both exhibit the same behavior so it doesn?t look like it is something that is special to a machine. I have not yet gotten to test a complete fresh install of windows as that is a bigger undertaking. Thanks, Felix From Eric.Granados at limelogic.be Thu May 5 20:04:32 2022 From: Eric.Granados at limelogic.be (Eric Granados) Date: Thu, 5 May 2022 20:04:32 +0000 Subject: Wireguard 0.5.3 on Windows - Huge performance issue when no network connection is up Message-ID: Hi Folks, Having this issue in corporate environments, that I can reproduce at will. The scenario is as follows: * Wireguard installed and properly configured * Boot the computer with NO physical network connection active * Open an Office document stored locally on the computer : takes between 15 seconds and up to 4 minutes * As soon as a physical network adapter comes up, even for a few seconds, the problem disappears and the same document opens in 1-2 seconds. The computer does *not* need to have internet access : "Upping" network card is enough. * Once an adapter has been up, I can put it down again and the problem won't appear again, until next computer reboot. * If, instead of "upping" an adapter, I unbind Tcp/Ip from the Wireguard adapter, the problem disappears; and reappears as soon as I bind again Tcp/Ip. Which is imho proof that Wireguard is causing this behaviour. Of course I guess that the "root cause" is actually Ms-Office, probably trying to reach something it can't reach (even though the document is local...) and waiting for a timeout. That would make sense, since in a way the Wireguard interface is "always up", Office probably "believes" that there is a network available. However, I sniffed the Wireguard adapter in this scenario, and Wireshark only shows DNS requests being sent (which, of course, receive no answer). In my case it is a big issue, because I have users who are trainers and, when they go to a customer site to give their trainings, they very often won't have any network connection provided by their customer, and in many cases are in locations where there is no mobile phone signal so they can't even share their mobile connection. Right now, the ugly workaround I have found is the following : * A scheduled task runs at computer startup, and disables the Wireguard Tcp/Ip binding * Another scheduled task is triggered when the NCSI (Network Connectivity Status Indicator) event 4042 is fired, which happens when a physical network adapter comes up, that re-enables the Tcp/Ip binding. But it is indeed an ugly workaround, so I'm posting here in the hope that : * Someone can look into this (I am no developer so totally unable to look at the code) * If not, at least hoping that my current workaround can be helpful to others who may encounter the same issue. I have a gut feeling that, due to the very nature of Wireguard ("always up"), there is no "structural" solution to this, but any suggestion is welcome. Sorry for the long post but I could not find a shorter way to describe the issue accurately ! From simon.karberg at agillic.com Mon May 9 20:04:27 2022 From: simon.karberg at agillic.com (Simon Karberg) Date: Mon, 9 May 2022 22:04:27 +0200 Subject: [MacOS] Multiple search domains settings based on config file Message-ID: Hi, I can see in my config file under DNS that I have our primary DNS server ip address and then added search domains with comma list after. On linux & Windows it seems to be set correctly but it's not being set through the MacOS client from the app store. I have tried to look through the source code to identify if the settings are there for the app but i'm not sure. I am on MacOS 12.13.1 (Monterey) in a M1 Max (arm64). App version: 1.0.15 (26) Go backend version: 2ef39d47 Best regards, Simon Karberg From amigan at gmail.com Wed May 11 13:48:28 2022 From: amigan at gmail.com (Dan Ponte) Date: Wed, 11 May 2022 09:48:28 -0400 Subject: [PATCH] wg-quick: freebsd: save mask of interface in save_config Message-ID: <20220511134827.81778-1-amigan@gmail.com> Other than the obvious benefits, this prevents "ifconfig: WARNING: setting interface address without mask is deprecated, default mask may not be correct." from appearing on the next start after save. Signed-off-by: Dan Ponte --- src/wg-quick/freebsd.bash | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/src/wg-quick/freebsd.bash b/src/wg-quick/freebsd.bash index b529ab2..5864a17 100755 --- a/src/wg-quick/freebsd.bash +++ b/src/wg-quick/freebsd.bash @@ -341,13 +341,15 @@ set_config() { } save_config() { - local old_umask new_config current_config address cmd + local old_umask new_config current_config network cidr address cmd new_config=$'[Interface]\n' - { read -r _; while read -r _ _ _ address _; do - new_config+="Address = $address"$'\n' + { read -r _; while read -r _ _ network address _; do + cidr=(${network//\// }) + new_config+="Address = $address/${cidr[1]}"$'\n' done } < <(netstat -I "$INTERFACE" -n -W -f inet) - { read -r _; while read -r _ _ _ address _; do - new_config+="Address = $address"$'\n' + { read -r _; while read -r _ _ network address _; do + cidr=(${network//\// }) + new_config+="Address = $address/${cidr[1]}"$'\n' done } < <(netstat -I "$INTERFACE" -n -W -f inet6) while read -r address; do [[ $address =~ ^nameserver\ ([a-zA-Z0-9_=+:%.-]+)$ ]] && new_config+="DNS = ${BASH_REMATCH[1]}"$'\n' -- 2.36.0 From felix.geschwindner at icloud.com Fri May 13 05:10:57 2022 From: felix.geschwindner at icloud.com (Felix Geschwindner) Date: Thu, 12 May 2022 22:10:57 -0700 Subject: WireGuard Windows client handshake packets appear to be blackholed Message-ID: <7C8C19EF-9076-4A65-9656-EEC28E688B4B@icloud.com> Hey folks, I sent a similar mail a week ago and it said it?s waiting for approval but haven?t gotten anything else back so I thought, try again since there were other mails on the list that came through in the meantime. I?ve been using WireGuard on my macOS, Linux & Windows machines for a while now and recently the Windows machines started to block WireGuard in a strange way. I?m using Windows 10 & 11 with the latest updates. WireGuard client version is v0.5.3. The config looks like this: [Interface] PrivateKey = Address = 10.0.0.10/32 DNS = 192.168.0.1 [Peer] PublicKey = AllowedIPs = 192.168.0.0/24 Endpoint = vpn.example.com:51820 When I activate the WireGuard VPN it reports that the connection is active and ready to go. I even see the new adapter created in the Windows network settings but when I try to ping resources behind the VPN, I get a ?General Failure? message from the command line. Pinging the local client VPN adapter IP works. First I tried a couple simple things that may help the WireGuard client to succeed: ? Reboot ? Run as administrator ? Re-install client ? Re-generate keys & config ? Try same config on a Mac to rule out mismatches (this works) ? Run WireGuard in Windows 7 compatibility mode ? Configure the TCP/IP stack in the registry to favor IPv4 over IPv6 ? Disable IPv6 entirely ? Add explicit firewall rule to allow WireGuard ports ? Disable firewall entirely ? Try full-tunnel via 0.0.0.0/0 in "AllowedIPs" None of the above points produced any change whatsoever. Finally I took to WireShark to see if it can help me identify where the packets get stuck and surprisingly WireShark doesn?t show ANY packets destined for the 51820 UDP port on ANY interface. Which is the point at which I ran out of ideas. I tried this on 2 different Windows machines and both exhibit the same behavior so it doesn?t look like it is something that is special to a machine. I have not yet gotten to test a complete fresh install of windows as that is a bigger undertaking. Thanks, Felix From dimitri.papadopoulos at cea.fr Sat May 21 13:02:42 2022 From: dimitri.papadopoulos at cea.fr (Dimitri Papadopoulos) Date: Sat, 21 May 2022 15:02:42 +0200 Subject: [PATCH] Fix typos found by codespell Message-ID: <9466bb1d-d6ee-4428-8132-a87f9db644c9@cea.fr> --- driver/wintun.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/driver/wintun.c b/driver/wintun.c index f3eea05..ad4b16b 100644 --- a/driver/wintun.c +++ b/driver/wintun.c @@ -49,7 +49,7 @@ ((((ULONG)(x)&0x000000ff) << 24) | (((ULONG)(x)&0x0000ff00) << 8) | (((ULONG)(x)&0x00ff0000) >> 8) | \ (((ULONG)(x)&0xff000000) >> 24)) #else -# error "Unable to determine endianess" +# error "Unable to determine endianness" #endif #define TUN_MEMORY_TAG HTONL('wtun') @@ -107,7 +107,7 @@ typedef struct _TUN_REGISTER_RINGS_32 /* Size of the ring */ ULONG RingSize; - /* 32-bit addres of client allocated ring */ + /* 32-bit address of client allocated ring */ ULONG Ring; /* On send: An event created by the client the Wintun signals after it moves the Tail member of the send ring. -- 2.34.1 From peljasz at yahoo.co.uk Thu May 26 10:36:37 2022 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 26 May 2022 11:36:37 +0100 Subject: something affects wg iface - how to troubleshoot ? References: <84e28e50-caec-072e-f916-870b63110432.ref@yahoo.co.uk> Message-ID: <84e28e50-caec-072e-f916-870b63110432@yahoo.co.uk> Hi guys. I have quite a peculiar case which possibly might interest anybody - as oppose to just resolving an issue. I use a very popular monitoring tool 'monit' to monit my wg0 iface and that works okey, meaning 'monit' does not see any issue with wg0, but _only_ if 'qbittorrent' is _not_ running! When 'qbittorrent' is running 'monit' is reporting: 'wg0' 5 upload errors detected 'wg0' trying to restart 'wg0' stop: '/usr/bin/systemctl stop wg-quick at wg0.service' 'wg0' start: '/usr/bin/systemctl start wg-quick at wg0.service' 'wg0' download errors check succeeded in my case monit's action is to restart wg0 iface. 'qbittorrent' is not, should not be, particularly interested in wg0 iface. What do you think is happening there? I'm on Centos 9. Is some kind of leakage or something more sinister happening there? Lastly, how to investigate this, how to tell what is happening to wg iface? many thanks, L. From kjopek at gmail.com Wed May 18 09:24:53 2022 From: kjopek at gmail.com (Konrad Sewillo-Jopek) Date: Wed, 18 May 2022 11:24:53 +0200 Subject: if_wg on BeagleBone black Message-ID: <4c3ffcc9-82e2-6295-03b3-d26b3bf3d7fc@gmail.com> Hey folks, here is what I get when trying to ping anything else after if_wg is up and running on my BeagleBone Black: root at beagle:~ # wg show interface: wg0 public key: ? private key: (hidden) ? listening port: 39856 peer: ? preshared key: (hidden) ? endpoint: ? allowed ips: 10.11.12.0/24 root at beagle:~ # ping 10.11.12.1 PING 10.11.12.1 (10.11.12.1): 56 data bytes Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xd7195be0 FSR=00000005, FAR=00000278, spsr=40000013 r0 =00000000, r1 =00000000, r2 =00000001, r3 =00000000 r4 =d1626a18, r5 =d1626b2c, r6 =0000005c, r7 =00000000 r8 =d159c000, r9 =d1493900, r10=d7cd7aa8, r11=d7195c78 r12=d7b378f8, ssp=d7195c70, slr=d7b14c80, pc =c042f854 panic: Fatal abort cpuid = 0 time = 1652353064 KDB: stack backtrace: #0 0xc0355b70 at kdb_backtrace+0x48 #1 0xc02fcb50 at vpanic+0x170 #2 0xc02fc9e0 at vpanic+0 #3 0xc061bc14 at abort_align+0 #4 0xc061b704 at abort_handler+0x2a0 #5 0xc05fac68 at exception_exit+0 #6 0xc042f854 at if_inc_counter+0xc #7 0xd7b14c80 at wg_softc_handshake_receive+0x8d0 #8 0xc035466c at gtaskqueue_run_locked+0x1b8 #9 0xc0354204 at gtaskqueue_thread_loop+0x1b0 #10 0xc02b4b38 at fork_exit+0xc0 #11 0xc05fabf8 at swi_exit+0 Uptime: 3m23s Automatic reboot in 15 seconds - press a key on the console to abort Do you know, what may be the cause? Some stuff on the path suggests some counters are misaligned. Regards Konrad Sewi??o-Jopek From joakim at tallinger.se Sun May 22 11:15:11 2022 From: joakim at tallinger.se (Joakim Tallinger) Date: Sun, 22 May 2022 13:15:11 +0200 Subject: Building Directly In Tree with Buildroot Message-ID: <5DE587F6-FA8E-4935-A75F-4373A9D1CA89@tallinger.se> Hi, I?m using Buildroot to build a custom linux kernel (4.14.185) for an embedded system, for which I now want to add Wireguard to. I have one config for initrd and another one for rootfs. I added ?BR2_PACKAGE_WIREGUARD_LINUX_COMPAT? to initrd and ?BR2_PACKAGE_WIREGUARD_TOOLS? to rootfs. It downloads the source and builds it accordingly. I can see the module is there before initrd image is created, but since system is booted with initrd, and then rootfs is mounted I can?t access the module with modprobe. To my understanding I need to solve this by building Wireguard in tree (i.e where module is always active)? Which brings me to the question on how to apply the kernel tree script ?create-patch.sh?. I can manually navigate to the linux src directory and run it, but that won?t work as part of the Buildroot process. I guess I need to add a pre-build step to run the script to patch the linux src, then add CONFIG_WIREGUARD=y to my custom kernel config. Would this be the correct way to do it? Or is there some easier way to manage it? Br, Joakim From ashish.is at lostca.se Tue May 31 04:51:23 2022 From: ashish.is at lostca.se (Ashish) Date: Tue, 31 May 2022 04:51:23 +0000 Subject: something affects wg iface - how to troubleshoot ? In-Reply-To: <84e28e50-caec-072e-f916-870b63110432@yahoo.co.uk> References: <84e28e50-caec-072e-f916-870b63110432.ref@yahoo.co.uk> <84e28e50-caec-072e-f916-870b63110432@yahoo.co.uk> Message-ID: <20220531045123.ite3fv33ozmtcr73@chateau.d.if> On Thu, May 26, 2022 at 11:36:37AM +0100, lejeczek wrote: > Hi guys. > > I have quite a peculiar case which possibly might interest anybody - as > oppose to just resolving an issue. > I use a very popular monitoring tool 'monit' to monit my wg0 iface and that > works okey, meaning 'monit' does not see any issue with wg0, but _only_ if > 'qbittorrent' is _not_ running! > When 'qbittorrent' is running 'monit' is reporting: > > 'wg0' 5 upload errors detected > 'wg0' trying to restart > 'wg0' stop: '/usr/bin/systemctl stop wg-quick at wg0.service' > 'wg0' start: '/usr/bin/systemctl start wg-quick at wg0.service' > 'wg0' download errors check succeeded > > in my case monit's action is to restart wg0 iface. > 'qbittorrent' is not, should not be, particularly interested in wg0 iface. > > What do you think is happening there? I'm on Centos 9. Is some kind of > leakage or something more sinister happening there? > Lastly, how to investigate this, how to tell what is happening to wg iface? If I've to make a rough guess without looking at your exact monit configuration, I would say qbittorrent is choking the network interface, causing the wireguard packets to be delayed: You can verify this by: - stopping all the upload/download activity in qbittorrent - if previous step works as expected for you, then you can implement some speed throttling in qbittorrent You can also verifying by tcpdump-ing the underlying interface (e.g. eth0, and not wg0) for the wireguard traffic and see if it's going out, and coming back in as expected. HTH -- Ashish | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 "If I destroy you, what business is it of yours ?" (Dark Forest, Liu Cixin) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From kevans at freebsd.org Tue May 31 05:10:49 2022 From: kevans at freebsd.org (Kyle Evans) Date: Mon, 30 May 2022 22:10:49 -0700 Subject: if_wg on BeagleBone black In-Reply-To: <4c3ffcc9-82e2-6295-03b3-d26b3bf3d7fc@gmail.com> References: <4c3ffcc9-82e2-6295-03b3-d26b3bf3d7fc@gmail.com> Message-ID: On Thu, May 26, 2022 at 3:54 AM Konrad Sewillo-Jopek wrote: > > Hey folks, > > here is what I get when trying to ping anything else after > if_wg is up and running on my BeagleBone Black: > > root at beagle:~ # wg show > interface: wg0 > public key: > private key: (hidden) > listening port: 39856 > > peer: > preshared key: (hidden) > endpoint: > allowed ips: 10.11.12.0/24 > root at beagle:~ # ping 10.11.12.1 > PING 10.11.12.1 (10.11.12.1): 56 data bytes > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > trapframe: 0xd7195be0 > FSR=00000005, FAR=00000278, spsr=40000013 > r0 =00000000, r1 =00000000, r2 =00000001, r3 =00000000 > r4 =d1626a18, r5 =d1626b2c, r6 =0000005c, r7 =00000000 > r8 =d159c000, r9 =d1493900, r10=d7cd7aa8, r11=d7195c78 > r12=d7b378f8, ssp=d7195c70, slr=d7b14c80, pc =c042f854 > > panic: Fatal abort > cpuid = 0 > time = 1652353064 > KDB: stack backtrace: > #0 0xc0355b70 at kdb_backtrace+0x48 > #1 0xc02fcb50 at vpanic+0x170 > #2 0xc02fc9e0 at vpanic+0 > #3 0xc061bc14 at abort_align+0 > #4 0xc061b704 at abort_handler+0x2a0 > #5 0xc05fac68 at exception_exit+0 > #6 0xc042f854 at if_inc_counter+0xc > #7 0xd7b14c80 at wg_softc_handshake_receive+0x8d0 > #8 0xc035466c at gtaskqueue_run_locked+0x1b8 > #9 0xc0354204 at gtaskqueue_thread_loop+0x1b0 > #10 0xc02b4b38 at fork_exit+0xc0 > #11 0xc05fabf8 at swi_exit+0 > Uptime: 3m23s > Automatic reboot in 15 seconds - press a key on the console to abort > > Do you know, what may be the cause? > Some stuff on the path suggests some counters are misaligned. > This looks like FreeBSD, which version/branch is this from? If this is 13.1, you'll need to rebuild the kmod -- there was a KBI break somewhere, and it wasn't reported during any of the -BETA/-RC otherwise I would've tried to track it down and mitigate it. :-( Thanks, Kyle Evans From thomas at datawire.io Fri May 27 14:09:14 2022 From: thomas at datawire.io (Thomas Hallgren) Date: Fri, 27 May 2022 14:09:14 -0000 Subject: Incompatibility between wintun.dll and go module Message-ID: Hi, We're using the wintun.dll and the go module golang.zx2c4.com/wireguard/windows v0.5.3 in our product. The dll initialization fails when upgrading the wintun.dll to version 0.14.1 (or 0.14, it doesn't matter). 0.13 works fine. Relevant stack trace below. Thanks for an excellent library. Without it, it would be much harder to port our product to Windows. unexpected fault address 0xffffffffffffffff fatal error: fault [signal 0xc0000005 code=0x0 addr=0xffffffffffffffff pc=0xe8b29d] goroutine 65 [running, locked to thread]: runtime.throw({0x27b93d9?, 0x0?}) runtime/panic.go:992 +0x76 fp=0xc000a393d8 sp=0xc000a393a8 pc=0xce8996 runtime.sigpanic() runtime/signal_windows.go:261 +0x125 fp=0xc000a39420 sp=0xc000a393d8 pc=0xcfbb05 golang.org/x/sys/windows.UTF16PtrToString(0x240e6a0?) golang.org/x/sys at v0.0.0-20220209214540-3681064d5158/windows/syscall_windows.go:132 +0x1d fp=0xc000a39468 sp=0xc000a39420 pc=0xe8b29d golang.zx2c4.com/wireguard/tun/wintun.setupLogger.func1(0xc000057590?, 0x0?) golang.zx2c4.com/wireguard at v0.0.0-20210427022245-097af6e1351b/tun/wintun/wintun_windows.go:53 +0x1c fp=0xc000a394b0 sp=0xc000a39468 pc=0x1f321bc runtime.call16(0x0, 0x28df468, 0xc000a39538, 0x0, 0x0, 0x10, 0xc000a39790) runtime/asm_amd64.s:701 +0x50 fp=0xc000a394d0 sp=0xc000a394b0 pc=0xd14530 runtime.callbackWrap(0x7c95ffebc0) runtime/syscall_windows.go:378 +0x134 fp=0xc000a398b0 sp=0xc000a394d0 pc=0xd04074 runtime.cgocallbackg1(0xd03f40, 0x0?, 0x0) runtime/cgocall.go:314 +0x2ca fp=0xc000a39980 sp=0xc000a398b0 pc=0xcb4b8a runtime.cgocallbackg(0xc000583380?, 0x300000002?, 0xc000583380?) runtime/cgocall.go:233 +0x106 fp=0xc000a39a18 sp=0xc000a39980 pc=0xcb47c6 runtime.cgocallbackg(0xd03f40, 0x7c95ffebc0, 0x0) :1 +0x36 fp=0xc000a39a40 sp=0xc000a39a18 pc=0xd18356 runtime.cgocallback(0xcb464b, 0xd17be0, 0xc0001002c0) runtime/asm_amd64.s:971 +0xd7 fp=0xc000a39a68 sp=0xc000a39a40 pc=0xd160f7 runtime.systemstack_switch() runtime/asm_amd64.s:436 fp=0xc000a39a70 sp=0xc000a39a68 pc=0xd13fe0 runtime.cgocall(0xd17be0, 0xc0001002c0) runtime/cgocall.go:167 +0xab fp=0xc000a39aa8 sp=0xc000a39a70 pc=0xcb464b syscall.SyscallN(0x7ffc169c3a90?, {0xc000a39b40?, 0x3?, 0x0?}) runtime/syscall_windows.go:538 +0x109 fp=0xc000a39b20 sp=0xc000a39aa8 pc=0xd12de9 syscall.Syscall(0xc000479590?, 0x1a428c8510a?, 0x1a428c8510a?, 0x0?, 0x0?) runtime/syscall_windows.go:476 +0x3b fp=0xc000a39b68 sp=0xc000a39b20 pc=0xd129fb golang.zx2c4.com/wireguard/tun/wintun.(*Pool).OpenAdapter(0xc000187800, {0x27b825c?, 0x1a403910598?}) golang.zx2c4.com/wireguard at v0.0.0-20210427022245-097af6e1351b/tun/wintun/wintun_windows.go:89 +0xad fp=0xc000a39bd8 sp=0xc000a39b68 pc=0x1f3256d golang.zx2c4.com/wireguard/tun.CreateTUNWithRequestedGUID({0x27b825c, 0x4}, 0x0?, 0x0) golang.zx2c4.com/wireguard at v0.0.0-20210427022245-097af6e1351b/tun/tun_windows.go:75 +0x4d fp=0xc000a39c50 sp=0xc000a39bd8 pc=0x1f3384d golang.zx2c4.com/wireguard/tun.CreateTUN(...) golang.zx2c4.com/wireguard at v0.0.0-20210427022245-097af6e1351b/tun/tun_windows.go:63