From nico.schottelius at ungleich.ch Sun May 2 11:02:28 2021 From: nico.schottelius at ungleich.ch (Nico Schottelius) Date: Sun, 02 May 2021 13:02:28 +0200 Subject: Multiple Keys per Peer Message-ID: <87wnshs8jf.fsf@ungleich.ch> Good morning, when running a lot of VPN connections using wireguard, there are some questions we see quite often from users, two of which I'd like to discuss here: Multiple keys per Peer ---------------------- Users often ask for sharing their connection with multiple devices. The obvious solution is for users to setup their own VPN endpoint with the first key and then reshare themselves. However, this is not feasible in many end user situations. Conceptually I see it problematic to assign multiple keys per Peer as the routing from outside ("where should this packet go to"?) might become ambiguous. One counter option would be to allow a peer to signal that it uses a certain part of the AllowedIPs. In comparison to layer 2 networks, I see two approaches: 1) a bit similar to ARP/NDP, client addresses are learned 2) similar to dhcp-pd, clients "requesting" (in this context more: announcing) that they use a certain sub-range. Protocol wise I'd imagine this to be rather simple: side a: I want to use 2001:db8:a:b::/64 side b: - checking your allowed IPs covers that prefix -> no ignore - checking whether the amount of sub routes is not exceeded - and/or checking whether the sub-prefix length is of minimum size (especially import for IPv6) - yes: adjust routing table, insert more specific route (with/without confirm probably should be modeld in tamarin) What are your thoughts about an extension of wireguard with this? If there are other suggestions to allow users to decide themselves how to split a range, let's say a /48 IPv6 network, without setting up their own redistribution node, I'd also be interested in hearing that. Best regards, Nico p.s.: I have seen some old messages in the archive about this topic, but did not a conclusion in it. -- Sustainable and modern Infrastructures by ungleich.ch From jilkara.vivekvardhan35 at gmail.com Sat May 1 04:19:58 2021 From: jilkara.vivekvardhan35 at gmail.com (Vivekvardhan Jilkara) Date: Sat, 1 May 2021 09:49:58 +0530 Subject: Why there are no API exposed to connect or disconnect the network interface Message-ID: Hi team, I have been going through the wireguard-windows module to understand its usage for one of my requirements. My requirement is as follows. 1. Create the virtual network interface/ network tunnel. This I can achieve by calling, CreateTun 2. Eventually, based on some trigger points, I want to open this created tunnel and then do the connection/disconnection(OpenSession/CloseSession). Following are my queries. 1. Like the CreatTun method, I expected a method called GetTun(string), which would simply call the OpenAdapter method(in the wintun package) and return the instance of the device. Is there any reason for not providing this? 2. In the device interface(in tun package), the APIs that are provided are operating on the adapter against the tunnel. I thought, if this interface would have had APIs, something called StartSession and EndSession, using those APIs I could have connected or disconnected the connection for that tunnel. Is there any reason for not providing these? Also, I am doubting whether the expectations that I set are incorrect. If YES, I request you to help me to understand the reason AND please guide me if there is any way to achieve the above requirements without these APIs being expected. Thanks in advance. Regards, Vivekvardhan. From rm at romanrm.net Sun May 2 11:43:44 2021 From: rm at romanrm.net (Roman Mamedov) Date: Sun, 2 May 2021 16:43:44 +0500 Subject: Multiple Keys per Peer In-Reply-To: <87wnshs8jf.fsf@ungleich.ch> References: <87wnshs8jf.fsf@ungleich.ch> Message-ID: <20210502164344.039fe960@natsu> On Sun, 02 May 2021 13:02:28 +0200 Nico Schottelius wrote: > when running a lot of VPN connections using wireguard, there are some > questions we see quite often from users, two of which I'd like to > discuss here: > > Multiple keys per Peer > ---------------------- > > Users often ask for sharing their connection with multiple > devices. The obvious solution is for users to setup their own VPN > endpoint with the first key and then reshare themselves. However, this > is not feasible in many end user situations. The prime and the most straightforward solution is to give each user multiple keys, and let them connect from each endpoint as an independent Peer. The rest of what you propose appears to be a set of bizarre hacks because you don't want to do the above, because "(reasons)". Maybe start with detailing those reasons first, or reconsidering if they are *really* that important and unsurmountable :) > Conceptually I see it problematic to assign multiple keys per Peer as > the routing from outside ("where should this packet go to"?) might > become ambiguous. One counter option would be to allow a peer to signal > that it uses a certain part of the AllowedIPs. In comparison to layer 2 > networks, I see two approaches: 1) a bit similar to ARP/NDP, client > addresses are learned 2) similar to dhcp-pd, clients "requesting" (in > this context more: announcing) that they use a certain sub-range. > > Protocol wise I'd imagine this to be rather simple: > > side a: I want to use 2001:db8:a:b::/64 > side b: > - checking your allowed IPs covers that prefix -> no ignore > - checking whether the amount of sub routes is not exceeded > - and/or checking whether the sub-prefix length is of minimum size > (especially import for IPv6) > - yes: adjust routing table, insert more specific route > (with/without confirm probably should be modeld in tamarin) > > What are your thoughts about an extension of wireguard with this? > > If there are other suggestions to allow users to decide themselves how > to split a range, let's say a /48 IPv6 network, without setting up their > own redistribution node, I'd also be interested in hearing that. -- With respect, Roman From nico.schottelius at ungleich.ch Sun May 2 12:06:53 2021 From: nico.schottelius at ungleich.ch (Nico Schottelius) Date: Sun, 02 May 2021 14:06:53 +0200 Subject: Multiple Keys per Peer In-Reply-To: <20210502164344.039fe960@natsu> References: <87wnshs8jf.fsf@ungleich.ch> <20210502164344.039fe960@natsu> Message-ID: <87pmy9s5k2.fsf@ungleich.ch> Roman Mamedov writes: > On Sun, 02 May 2021 13:02:28 +0200 > Nico Schottelius wrote: > >> when running a lot of VPN connections using wireguard, there are some >> questions we see quite often from users, two of which I'd like to >> discuss here: >> >> Multiple keys per Peer >> ---------------------- >> >> Users often ask for sharing their connection with multiple >> devices. The obvious solution is for users to setup their own VPN >> endpoint with the first key and then reshare themselves. However, this >> is not feasible in many end user situations. > > The prime and the most straightforward solution is to give each user multiple > keys, and let them connect from each endpoint as an independent Peer. > > The rest of what you propose appears to be a set of bizarre hacks because > you don't want to do the above, because "(reasons)". Maybe start with > detailing those reasons first, or reconsidering if they are *really* that > important and unsurmountable :) Practically speaking our VPN are currently rather "dumb" and only know about /48's (usually one VPN server is responsible for a /40). And in practice, we are not so much interested in knowing how people split their tunnels, so we considers this more of a dynamic routing than a static configuration. However, I see your point that we could update our systems for pre-processing the routing logic and letting users split on a static basis and with that keeping the wireguard protocol more simple. I'd say fair enough and thanks for the pointer! Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch From Jason at zx2c4.com Mon May 3 08:01:04 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 03 May 2021 10:01:04 +0200 Subject: [ANNOUNCE] wireguard-freebsd snapshot v0.0.20210502 is available Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, An experimental snapshot, v0.0.20210502, of WireGuard for FreeBSD has been been tagged in the git repository. At this time this code is new, unvetted, possibly buggy, and should be considered "experimental". It might contain security issues. We gladly welcome your testing and bug reports, but do keep in mind that this code is new, so some caution should be exercised at the moment for using it in mission critical environments. == Changes == * if_wg: defragment mbufs early on * if_wg: ensure packet is not shared before writing These should improve performance and make sure everything works with functions like sendfile(2). * if_wg: return to m temporary variable style * if_wg: pad packets properly * if_wg: don't memcpy data for no reason * if_wg: don't double increment error counter * wg_cookie: zero before init in selftest for witness * wg_noise: cleanup counter algorithm Various small correctness fixes. This snapshot contains commits from: Jason A. Donenfeld. The source repository is available at the usual location: git clone https://git.zx2c4.com/wireguard-freebsd This snapshot is available in compressed tarball form: https://git.zx2c4.com/wireguard-freebsd/snapshot/wireguard-freebsd-0.0.20210502.tar.xz SHA2-256: cd59a0a711308083e40ac5e7e26abc63c8b1f4615a9d66f73f2398388b8e7b9b Thank you, Jason Donenfeld -----BEGIN PGP SIGNATURE----- iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAmCPrbAQHGphc29uQHp4 MmM0LmNvbQAKCRBJ/HASpd4DroPhEADWbUA86iVDtnAdXgVLuaZfc+5gXYJQv8GV EzOECSES5iG4PAVXqZHjeTcY+mj5HxTRmNUz00ci1eVeZISFojr41084dm8/pv6y Er5LFxHXLDJRIT6o2ODadE1pxKE7ada/PgicLlUgX9gYg5VPGqoYAKrnrEBBOnmF /9PRSsHYTGdw7kPXBfOZDafjJfrnYe/NXg7QCjwl/Fi1T3+omtbCSsxIs11XGuzf 3EjXoEVgGRRRtY0ibvO13tqEb1Q8KUVe4SHFIe2Hbbc/X9ZI6RKADzIqaqTMsxHa sV2jTh4XpOZcy9tf2yi0M/r6pwO+GJ/DqqKqWeWLapHInQS/TIPmj0P0fpQ8aNtz nr0Z++DQXJxnVuiT226mpcAI8z6YMw5JNO/mGUhnNney7lz9vQA8i6MGBwZlC4po trP/QxtBgwT/zPy6lb7Bhgtl3M5OnuHzFB9nsSKfsfilsWqAmX4lbdJ6DfJ0hLtZ 1WNH7uWt623HpL3KmFgA9ACdpZGh5zBqF8E7pHl7F+XVWT4BSIrUdEb4vEPVi4PV VeQUPmob5lbhghvEOi8F+uzflflOMdO5Z0W0iVqIST1AZywnrKqBRId5l6+sGXCf ZxuMLlv/KM+3nF7Xol9iEuksg4NnPr+QVxrn1chDcUkDb8nZDtVxDLd627ojQBZD miKJ6+4Z/g== =rFq4 -----END PGP SIGNATURE----- From manojav at manojav.com Sun May 2 21:44:04 2021 From: manojav at manojav.com (Manojav Sridhar) Date: Sun, 2 May 2021 17:44:04 -0400 Subject: kp's and mem corruption? Message-ID: Hi Jason, Great work on the Freebsd kmod so far! Couple of issues to report. I am running the wireguard-kmod-0.0.20210428 snapshot on my pfsense router. I am working with the pfSense-pkg-Wireguard effort in building the WG package. Admittedly I am mostly testing and providing some UI code. However I have come across 2 errors. First one is a KP that happened sometime today. FreeBSD pfsense 12.2-STABLE FreeBSD 12.2-STABLE 1b709158e581(RELENG_2_5_0) pfSense amd64 Here is the stack trace from the KP https://pastebin.com/4bjdzYas db:0:kdb.enter.default> bt Tracing pid 0 tid 100402 td 0xfffff800c67b6740 kdb_enter() at kdb_enter+0x37/frame 0xfffffe004d02c4b0 vpanic() at vpanic+0x197/frame 0xfffffe004d02c500 panic() at panic+0x43/frame 0xfffffe004d02c560 trap_fatal() at trap_fatal+0x391/frame 0xfffffe004d02c5c0 trap() at trap+0x67/frame 0xfffffe004d02c6d0 calltrap() at calltrap+0x8/frame 0xfffffe004d02c6d0 --- trap 0x9, rip = 0xffffffff840fd580, rsp = 0xfffffe004d02c7a0, rbp = 0xfffffe004d02c7e0 --- noise_remote_index_insert() at noise_remote_index_insert+0xb0/frame 0xfffffe004d02c7e0 noise_consume_initiation() at noise_consume_initiation+0x6bb/frame 0xfffffe004d02ca10 wg_softc_handshake_receive() at wg_softc_handshake_receive+0x27a/frame 0xfffffe004d02cb20 gtaskqueue_run_locked() at gtaskqueue_run_locked+0x121/frame 0xfffffe004d02cb80 gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xb6/frame 0xfffffe004d02cbb0 fork_exit() at fork_exit+0x7e/frame 0xfffffe004d02cbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe004d02cbf0 Second issue is that I am seeing memory silent corruption where the pfSense UI stops responding and serves up invalid files. Reboot fixes it. I have NOT noticed this issue with the 0415 snapshot; this happened both in the 0424 and 0428 snapshots. While I cannot definitively say its wg related, that is the only bit changing on the boxes. Thanks Manoj From Jason at zx2c4.com Mon May 3 13:07:15 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 3 May 2021 15:07:15 +0200 Subject: kp's and mem corruption? In-Reply-To: References: Message-ID: Hi Manojav, On Mon, May 3, 2021 at 3:05 PM Manojav Sridhar wrote: > --- trap 0x9, rip = 0xffffffff840fd580, rsp = 0xfffffe004d02c7a0, rbp = > 0xfffffe004d02c7e0 --- > noise_remote_index_insert() at noise_remote_index_insert+0xb0/frame > 0xfffffe004d02c7e0 > noise_consume_initiation() at noise_consume_initiation+0x6bb/frame > 0xfffffe004d02ca10 > wg_softc_handshake_receive() at wg_softc_handshake_receive+0x27a/frame > 0xfffffe004d02cb20 Do you know how to reproduce this? Do you have the symbol file anywhere? Otherwise, do you think you could send me (off list) your if_wg.ko file that produced this stack trace? Then I can put it into the disassembler. > Second issue is that I am seeing memory silent corruption where the pfSense > UI stops responding and serves up invalid files. Fixed in https://lists.zx2c4.com/pipermail/wireguard/2021-May/006694.html . Jason From Jason at zx2c4.com Mon May 3 15:08:22 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 3 May 2021 17:08:22 +0200 Subject: kp's and mem corruption? In-Reply-To: References: Message-ID: Hey again, Thanks for the .ko you sent me. That was helpful in tracking down the bug, which Matt and I have now fixed here: https://git.zx2c4.com/wireguard-freebsd/commit/?id=c69fb61b94341027ea3c539bcf96d9fe03f65fa5 The commit message includes a little bash reproducer that hit the same crash in my tests, making me somewhat confident we squashed the right one. Jason From Jason at zx2c4.com Mon May 3 15:30:56 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 3 May 2021 17:30:56 +0200 Subject: kp's and mem corruption? In-Reply-To: References: Message-ID: On Mon, May 3, 2021 at 5:27 PM Manojav Sridhar wrote: > I tried the bash script on both bare metal box and virtualbox pfsense > box. both ran for a few minutes okay. How long does it take to happen? > I am testing with the 0428 snapshot. Try changing in wg_noise.c: #define HT_INDEX_SIZE (1 << 13) to #define HT_INDEX_SIZE (1 << 3) And then you'll see it hit pretty quickly. From manojav at manojav.com Mon May 3 13:33:22 2021 From: manojav at manojav.com (Manojav Sridhar) Date: Mon, 3 May 2021 09:33:22 -0400 Subject: kp's and mem corruption? In-Reply-To: References: Message-ID: Thanks. I have responded off list onr your other request. Will continue to test on the latest snapshots! On Mon, May 3, 2021 at 9:07 AM Jason A. Donenfeld wrote: > > Hi Manojav, > > On Mon, May 3, 2021 at 3:05 PM Manojav Sridhar wrote: > > --- trap 0x9, rip = 0xffffffff840fd580, rsp = 0xfffffe004d02c7a0, rbp = > > 0xfffffe004d02c7e0 --- > > noise_remote_index_insert() at noise_remote_index_insert+0xb0/frame > > 0xfffffe004d02c7e0 > > noise_consume_initiation() at noise_consume_initiation+0x6bb/frame > > 0xfffffe004d02ca10 > > wg_softc_handshake_receive() at wg_softc_handshake_receive+0x27a/frame > > 0xfffffe004d02cb20 > > Do you know how to reproduce this? Do you have the symbol file > anywhere? Otherwise, do you think you could send me (off list) your > if_wg.ko file that produced this stack trace? Then I can put it into > the disassembler. > > > Second issue is that I am seeing memory silent corruption where the pfSense > > UI stops responding and serves up invalid files. > > Fixed in https://lists.zx2c4.com/pipermail/wireguard/2021-May/006694.html . > > Jason From manojav at manojav.com Mon May 3 15:27:18 2021 From: manojav at manojav.com (Manojav Sridhar) Date: Mon, 3 May 2021 11:27:18 -0400 Subject: kp's and mem corruption? In-Reply-To: References: Message-ID: Jason, Thanks for the follow up and bash to script to ensure help re-pro it. I am guessing my constant restarting of the tunnels when testing the pfSense based UI we are building triggered the scenario your bash script creates. I tried the bash script on both bare metal box and virtualbox pfsense box. both ran for a few minutes okay. How long does it take to happen? I am testing with the 0428 snapshot. Manoj On Mon, May 3, 2021 at 11:08 AM Jason A. Donenfeld wrote: > > Hey again, > > Thanks for the .ko you sent me. That was helpful in tracking down the > bug, which Matt and I have now fixed here: > > https://git.zx2c4.com/wireguard-freebsd/commit/?id=c69fb61b94341027ea3c539bcf96d9fe03f65fa5 > > The commit message includes a little bash reproducer that hit the same > crash in my tests, making me somewhat confident we squashed the right > one. > > Jason From manojav at manojav.com Mon May 3 15:32:43 2021 From: manojav at manojav.com (Manojav Sridhar) Date: Mon, 3 May 2021 11:32:43 -0400 Subject: kp's and mem corruption? In-Reply-To: References: Message-ID: Ah. Understood. I am not set up to build for freebsd yet ko. But I can leave it running on my test box for a bit. On Mon, May 3, 2021 at 11:31 AM Jason A. Donenfeld wrote: > > On Mon, May 3, 2021 at 5:27 PM Manojav Sridhar wrote: > > I tried the bash script on both bare metal box and virtualbox pfsense > > box. both ran for a few minutes okay. How long does it take to happen? > > I am testing with the 0428 snapshot. > > Try changing in wg_noise.c: > > #define HT_INDEX_SIZE (1 << 13) > > to > > #define HT_INDEX_SIZE (1 << 3) > > And then you'll see it hit pretty quickly. From manojav at manojav.com Mon May 3 15:34:41 2021 From: manojav at manojav.com (Manojav Sridhar) Date: Mon, 3 May 2021 11:34:41 -0400 Subject: kp's and mem corruption? In-Reply-To: References: Message-ID: Just happened! so yeah that was it on the trigger. Once Cmac builds the ko for me I will test it again! Again thanks so much! On Mon, May 3, 2021 at 11:32 AM Manojav Sridhar wrote: > > Ah. Understood. I am not set up to build for freebsd yet ko. But I can > leave it running on my test box for a bit. > > On Mon, May 3, 2021 at 11:31 AM Jason A. Donenfeld wrote: > > > > On Mon, May 3, 2021 at 5:27 PM Manojav Sridhar wrote: > > > I tried the bash script on both bare metal box and virtualbox pfsense > > > box. both ran for a few minutes okay. How long does it take to happen? > > > I am testing with the 0428 snapshot. > > > > Try changing in wg_noise.c: > > > > #define HT_INDEX_SIZE (1 << 13) > > > > to > > > > #define HT_INDEX_SIZE (1 << 3) > > > > And then you'll see it hit pretty quickly. From Jason at zx2c4.com Mon May 3 15:35:01 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 3 May 2021 17:35:01 +0200 Subject: kp's and mem corruption? In-Reply-To: References: Message-ID: On Mon, May 3, 2021 at 5:33 PM Manojav Sridhar wrote: > > Ah. Understood. I am not set up to build for freebsd yet ko. But I can > leave it running on my test box for a bit. Ah, don't worry about it. The trigger was sufficient for my purposes, but it doesn't need to be reproduced elsewhere necessarily. However, if you do wind up seeing this same bug again, using the latest master branch that contains the fix, please let me know, since that'd indicate I've done something wrong. Jason From Jason at zx2c4.com Mon May 3 15:35:41 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 3 May 2021 17:35:41 +0200 Subject: kp's and mem corruption? In-Reply-To: References: Message-ID: On Mon, May 3, 2021 at 5:35 PM Manojav Sridhar wrote: > > Just happened! so yeah that was it on the trigger. With 1 << 13 or 1 << 3? From manojav at manojav.com Mon May 3 15:36:57 2021 From: manojav at manojav.com (Manojav Sridhar) Date: Mon, 3 May 2021 11:36:57 -0400 Subject: kp's and mem corruption? In-Reply-To: References: Message-ID: With the same ko I sent you. 1<<13. I was just confirming I could trigger it. On Mon, May 3, 2021 at 11:35 AM Jason A. Donenfeld wrote: > > On Mon, May 3, 2021 at 5:35 PM Manojav Sridhar wrote: > > > > Just happened! so yeah that was it on the trigger. > > With 1 << 13 or 1 << 3? From Jason at zx2c4.com Mon May 3 17:56:33 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 3 May 2021 19:56:33 +0200 Subject: kp's and mem corruption? In-Reply-To: References: Message-ID: The code in here will repro the bug much faster: https://git.zx2c4.com/wireguard-freebsd/commit/?id=561f3a8f930cf2e44f493fa04d932ba9a2362cc5 From manojav at manojav.com Mon May 3 19:53:51 2021 From: manojav at manojav.com (Manojav Sridhar) Date: Mon, 3 May 2021 15:53:51 -0400 Subject: kp's and mem corruption? In-Reply-To: References: Message-ID: Jason, Thanks for the update. Yes it still triggers this on the current snapshot, which is built prior to your fix. I will retry it once you release a new snapshot. It seems quite a long shot that this occurred on my firewall in the first place. Glad it was reported and fixed. Onward! Thanks Manoj On Mon, May 3, 2021 at 1:56 PM Jason A. Donenfeld wrote: > > The code in here will repro the bug much faster: > > https://git.zx2c4.com/wireguard-freebsd/commit/?id=561f3a8f930cf2e44f493fa04d932ba9a2362cc5 From andy.melnikov at gmail.com Tue May 4 17:50:45 2021 From: andy.melnikov at gmail.com (Andrei Melnikov) Date: Tue, 4 May 2021 13:50:45 -0400 Subject: Android logs - entry index(342) is beyond type entryCount(180) Message-ID: My log is filled with the following messages: 05-04 13:39:46.569 18563 18563 W ResourceType: For resource 0x7f120156, entry index(342) is beyond type entryCount(180) 05-04 13:39:46.569 18563 18563 W ResourceType: For resource 0x7f12016d, entry index(365) is beyond type entryCount(180) Is it normal? -- Andrei From tomt at adslweb.co.uk Wed May 5 07:47:26 2021 From: tomt at adslweb.co.uk (tomt at adslweb.co.uk) Date: Wed, 05 May 2021 08:47:26 +0100 Subject: Android Client Won't Disconnect Tunnel Message-ID: Hi, I've installed WireGuard for Android v1.0.20210211 ( Go userspace backend v0.0.20201118 ) on to my Huawei P30 running Android 10 and my Lenovo Tab4 8Plus running Lineage OS Android 10 Both clients can connect to my OPNsense firewall via WireGuard and traffic routes as expected. OPNsense shows the connection in List Configuration and Handshake. When the VPN is active the 'key' is shown in the status bar and all is working fine. When I disable the client using the slider the 'key' disappears from the statue bar, but OPNsense still shows the connection as active and data can still route from the phone or tablet via the VPN, even though I've disabled it. If I check the client log, they both contain entries similar to the following: 05-05 08:32:08.180 31602 31629 I WireGuard/GoBackend: Bringing tunnel RemoteAccesss DOWN 05-05 08:32:08.181 31602 31629 D WireGuard/GoBackend/RemoteAccesss: Device closing 05-05 08:32:08.182 31602 32422 D WireGuard/GoBackend/RemoteAccesss: Routine: event worker - stopped 05-05 08:32:08.186 31602 31602 E WireGuard/ObservableTunnel: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String[] java.lang.String.split(java.lang.String)' on a null object reference 05-05 08:32:08.186 31602 31602 E WireGuard/ObservableTunnel: at com.wireguard.android.backend.GoBackend.getStatistics(GoBackend.java:4) 05-05 08:32:08.186 31602 31602 E WireGuard/ObservableTunnel: at com.wireguard.android.model.TunnelManager$getTunnelStatistics$2$1.invokeSuspend(TunnelManager.kt:5) 05-05 08:32:08.186 31602 31602 E WireGuard/ObservableTunnel: at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3) 05-05 08:32:08.186 31602 31602 E WireGuard/ObservableTunnel: at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:15) 05-05 08:32:08.186 31602 31602 E WireGuard/ObservableTunnel: at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:1) 05-05 08:32:08.186 31602 31602 E WireGuard/ObservableTunnel: at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:11) 05-05 08:32:08.227 31602 32198 D WireGuard/GoBackend/RemoteAccesss: Routine: TUN reader - stopped 05-05 08:32:08.228 31602 32198 D WireGuard/GoBackend/RemoteAccesss: Routine: receive incoming IPv4 - stopped 05-05 08:32:08.228 31602 32199 D WireGuard/GoBackend/RemoteAccesss: Routine: receive incoming IPv6 - stopped 05-05 08:32:08.228 31602 31629 D WireGuard/GoBackend/RemoteAccesss: peer(MqVe?+q28) - Stopping... 05-05 08:32:08.228 31602 32198 D WireGuard/GoBackend/RemoteAccesss: peer(MqVe?+q28) - Routine: sequential receiver - stopped 05-05 08:32:08.229 31602 32198 D WireGuard/GoBackend/RemoteAccesss: peer(MqVe?+q28) - Routine: sequential sender - stopped 05-05 08:32:08.229 31602 31629 D WireGuard/GoBackend/RemoteAccesss: Device closed 05-05 08:32:08.229 31602 32422 D WireGuard/GoBackend/RemoteAccesss: Routine: decryption worker - stopped Would that affect the disconnecting of the tunnel ? Has anyone had this issue with the client not actually disconnecting ? Any way to get this resolved ? Thanks From Jason at zx2c4.com Thu May 6 08:55:29 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Thu, 6 May 2021 10:55:29 +0200 Subject: Android Client Won't Disconnect Tunnel In-Reply-To: References: Message-ID: https://git.zx2c4.com/wireguard-android/commit/?id=d6a8e9d4dc8d6b5eb5b2e0341ef6e43aeb9c5c49 This should fix the exception in that log. The actual shutdown hang will hopefully be solved by the bump we pushed yesterday (still waiting Play Store approval). From Jason at zx2c4.com Thu May 6 09:20:08 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Thu, 06 May 2021 11:20:08 +0200 Subject: [ANNOUNCE] wireguard-freebsd snapshot v0.0.20210503 is available Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, An experimental snapshot, v0.0.20210503, of WireGuard for FreeBSD has been been tagged in the git repository. At this time this code is new, unvetted, possibly buggy, and should be considered "experimental". It might contain security issues. We gladly welcome your testing and bug reports, but do keep in mind that this code is new, so some caution should be exercised at the moment for using it in mission critical environments. == Changes == * if_wg: put event notifiers in main loop Should prevent connection stalls at sustained high speeds. * wg_noise: set handshake to dead before removing keypair Fixes an unlikely crash. * if_wg: destroy interfaces before uma zone Allows for removing the module while traffic is flowing. This snapshot contains commits from: Jason A. Donenfeld. The source repository is available at the usual location: git clone https://git.zx2c4.com/wireguard-freebsd This snapshot is available in compressed tarball form: https://git.zx2c4.com/wireguard-freebsd/snapshot/wireguard-freebsd-0.0.20210503.tar.xz SHA2-256: 96b2bceadc05dac2f026e203d1c0d25f114491afc8fbfc8d6f71c3de7f4a22f1 Thank you, Jason Donenfeld -----BEGIN PGP SIGNATURE----- iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAmCTtMEQHGphc29uQHp4 MmM0LmNvbQAKCRBJ/HASpd4Drtf0D/40Pz8jc7sNfLZYWYrQfra4gIgkScBkQFxU FqLnh3sG0Vc3lcLuhdXunowgTGXd7tTUW4HlQ5RcqtJimtogBI1bO8ZYo8lcYAJE wJPl7Jn5BEVDRKYUuXpDhtto5zpuWtyao/j1m3fyStnrZ19xqCMCsdCc5ULq2q7j m2Xo0z+ImqMM1l/PgnAM//aG1RvhJmzEQrMrYS6eBvTvphoDRjMztWT0UrkSM8EO Cn3EqH55KZZHz40654jLb8SxlDj8gJvFP3V0zzHvfcdDv/A3Shu1Mp8hSsmA0Da/ 280EZG9CjaAMsyEBBXnZGoFxgXq4xPGNVOC1N9TMnqUbh6q56yU/ABfYgC6yPD84 v//b6mJZ9DYITUq7t7h1TGgfAazD76C3O4v8JIHmRXg3xygsItWKO8QtoEWdtsBX Tqi45h5wq6Xn/dll2RkkeTkFa4lUKeSgpM3gWHNnBVHk8gNOHK1b9oujen59eOdK nN4vQ3DjXskDHMp4qabf9ffqD22C/BWQgBH8BTwmuAjSZq38SFBn/VGCzJwRR8OC VPYmlgo3aP6lbrIQqqSgZS8pGjR9m6w/aWuwQD+JOtEiiHU+VkivsKgeYCQAlctz /XvjxAqviEnxUEnJRDBmieGlLSEo+ED3F9Iu16n6E1WewdYhGh80G+KqlYTDQuvR c+Tmm2i3DA== =oVK+ -----END PGP SIGNATURE----- From Jason at zx2c4.com Thu May 6 12:10:06 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Thu, 6 May 2021 14:10:06 +0200 Subject: kp's and mem corruption? In-Reply-To: References: Message-ID: Hi Manojav, 0.0.20210503 is now in ports, which contains these fixes. Jason From manojav at manojav.com Thu May 6 15:59:25 2021 From: manojav at manojav.com (Manojav Sridhar) Date: Thu, 6 May 2021 11:59:25 -0400 Subject: kp's and mem corruption? In-Reply-To: References: Message-ID: Jason, With some help I was able to get the latest if_wg.ko built. I have been running the triggering bash script for a while now and not managed to trigger it. However prior to installing the latest snapshot it happened one more my on firewall (just provided as FYI) in the middle of the night as part of normal usage. Thanks for jumping on this! looking solid again! Manoj On Thu, May 6, 2021 at 8:10 AM Jason A. Donenfeld wrote: > > Hi Manojav, > > 0.0.20210503 is now in ports, which contains these fixes. > > Jason From piotrs at glosol.com Sat May 8 10:32:53 2021 From: piotrs at glosol.com (Piotr Sobczak) Date: Sat, 8 May 2021 12:32:53 +0200 Subject: Wintun - Requested GUID is already in use error on Windows 10 Message-ID: <000b01d743f5$815d8fc0$8418af40$@glosol.com> Hi, I am getting the following error message when trying to activate WireGuard tunnel on Windows 10 (app version 0.3.13): [Wintun] CreateAdapter: Requested GUID is already in use: {919CB63D-15C8-55F0-816A-801AF9AAE1AB}: Cannot create a file when that file already exists. (Code 0x000000B7) This seems to have started after upgrade to version 0.3.13. I tried uninstall and re-install of WireGuard but the issue persists. Any suggestions on how to fix it? Thanks, Piotr From Jason at zx2c4.com Sat May 8 14:24:57 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Sat, 8 May 2021 16:24:57 +0200 Subject: Wintun - Requested GUID is already in use error on Windows 10 In-Reply-To: <000b01d743f5$815d8fc0$8418af40$@glosol.com> References: <000b01d743f5$815d8fc0$8418af40$@glosol.com> Message-ID: Hi Piotr, Thanks for the report. I'm curious to know: do you have any other network adapters of the Wintun or WireGuard variety? What Windows version are you running? Would you mind sending a complete log? Thanks, Jason From piotrs at glosol.com Sat May 8 14:46:57 2021 From: piotrs at glosol.com (Piotr Sobczak) Date: Sat, 8 May 2021 16:46:57 +0200 Subject: Wintun - Requested GUID is already in use error on Windows 10 In-Reply-To: References: <000b01d743f5$815d8fc0$8418af40$@glosol.com> Message-ID: <000401d74418$ffecc590$ffc650b0$@glosol.com> Hi Jason, Thank you for the quick reply. I am attaching a full log. I am running on Windows 10 Enterprise 64bit. Full version is in the log. I do have other network adapters from Windscribe VPN app (screenshot attached). They were installed on the machine with the issue for a while though and I did not see this problem until now. Thanks, Piotr -----Original Message----- From: Jason A. Donenfeld Sent: Saturday, May 8, 2021 4:25 PM To: Piotr Sobczak Cc: wireguard at lists.zx2c4.com Subject: Re: Wintun - Requested GUID is already in use error on Windows 10 Hi Piotr, Thanks for the report. I'm curious to know: do you have any other network adapters of the Wintun or WireGuard variety? What Windows version are you running? Would you mind sending a complete log? Thanks, Jason -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wireguard-log-2021-05-08T163140.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2021-05-08 163703.png Type: image/png Size: 147479 bytes Desc: not available URL: From peljasz at yahoo.co.uk Sat May 8 16:31:58 2021 From: peljasz at yahoo.co.uk (lejeczek) Date: Sat, 8 May 2021 17:31:58 +0100 Subject: secondary IP on wg0 fails References: <204f6e7b-d594-c2c0-5242-1643055065c3.ref@yahoo.co.uk> Message-ID: <204f6e7b-d594-c2c0-5242-1643055065c3@yahoo.co.uk> Hi guys. I'm experiencing a pretty weird wireguard, or perhaps kernel/OS stack bits behavior. I have three nodes which all can ping each other on wg0's IPs but when I add a secondary IP: -> $ ip addr add 10.0.0.226/24 dev wg0 it gets weird, namely, say when that sec IP is on A -> B ping returns; C ping waits, no errors, no return B -> both C & A pings return C -> neither A nor B ping returns I'm on CentOS with 4.18.0-301.1.el8.x86_64. All three nodes are virtually identical kvm VMs. any suggestions as to what is not working here or how to troubleshoot are vey appreciated. many thanks, L. From rm at romanrm.net Sat May 8 16:50:39 2021 From: rm at romanrm.net (Roman Mamedov) Date: Sat, 8 May 2021 21:50:39 +0500 Subject: secondary IP on wg0 fails In-Reply-To: <204f6e7b-d594-c2c0-5242-1643055065c3@yahoo.co.uk> References: <204f6e7b-d594-c2c0-5242-1643055065c3.ref@yahoo.co.uk> <204f6e7b-d594-c2c0-5242-1643055065c3@yahoo.co.uk> Message-ID: <20210508215039.31f32aae@natsu> On Sat, 8 May 2021 17:31:58 +0100 lejeczek wrote: > I'm experiencing a pretty weird wireguard, or perhaps > kernel/OS stack bits behavior. > > I have three nodes which all can ping each other on wg0's > IPs but when I add a secondary IP: > > -> $ ip addr add 10.0.0.226/24 dev wg0 > > it gets weird, namely, say when that sec IP is on > A -> B ping returns; C ping waits, no errors, no return > B -> both C & A pings return > C -> neither A nor B ping returns > > I'm on CentOS with 4.18.0-301.1.el8.x86_64. > All three nodes are virtually identical kvm VMs. > > any suggestions as to what is not working here or how to > troubleshoot are vey appreciated. > many thanks, L. Did you add the new IP to AllowedIPs of that node on all the other nodes? Also remember that sets of AllowedIPs should be unique within the network, i.e. can't have the same AllowedIPs or ranges listed for multiple nodes at the same time. Setting it to the same /24 on all nodes will not work. If still not clear, better post your complete config (without keys). -- With respect, Roman From peljasz at yahoo.co.uk Sat May 8 18:49:06 2021 From: peljasz at yahoo.co.uk (lejeczek) Date: Sat, 8 May 2021 19:49:06 +0100 Subject: secondary IP on wg0 fails In-Reply-To: <20210508215039.31f32aae@natsu> References: <204f6e7b-d594-c2c0-5242-1643055065c3.ref@yahoo.co.uk> <204f6e7b-d594-c2c0-5242-1643055065c3@yahoo.co.uk> <20210508215039.31f32aae@natsu> Message-ID: On 08/05/2021 17:50, Roman Mamedov wrote: > On Sat, 8 May 2021 17:31:58 +0100 > lejeczek wrote: > >> I'm experiencing a pretty weird wireguard, or perhaps >> kernel/OS stack bits behavior. >> >> I have three nodes which all can ping each other on wg0's >> IPs but when I add a secondary IP: >> >> -> $ ip addr add 10.0.0.226/24 dev wg0 >> >> it gets weird, namely, say when that sec IP is on >> A -> B ping returns; C ping waits, no errors, no return >> B -> both C & A pings return >> C -> neither A nor B ping returns >> >> I'm on CentOS with 4.18.0-301.1.el8.x86_64. >> All three nodes are virtually identical kvm VMs. >> >> any suggestions as to what is not working here or how to >> troubleshoot are vey appreciated. >> many thanks, L. > Did you add the new IP to AllowedIPs of that node on all the other nodes? > > Also remember that sets of AllowedIPs should be unique within the network, > i.e. can't have the same AllowedIPs or ranges listed for multiple nodes at the > same time. Setting it to the same /24 on all nodes will not work. > > If still not clear, better post your complete config (without keys). > It's the same single subnet 10.0.0.0/24 and to reiterate - wg0's "primary" IPs can all ping each other. All nodes have, respectively: eg. node-B [peer] ... AllowedIPs = 10.0.0.1/32, 10.0.0.226/32 Endpoint = 10.1.1.223:51851 [peer] ... AllowedIPs = 10.0.0.3/32, 10.0.0.226/32 Endpoint = 10.1.1.225:51853 From peljasz at yahoo.co.uk Sun May 9 06:17:12 2021 From: peljasz at yahoo.co.uk (lejeczek) Date: Sun, 9 May 2021 07:17:12 +0100 Subject: secondary IP on wg0 fails In-Reply-To: <204f6e7b-d594-c2c0-5242-1643055065c3@yahoo.co.uk> References: <204f6e7b-d594-c2c0-5242-1643055065c3.ref@yahoo.co.uk> <204f6e7b-d594-c2c0-5242-1643055065c3@yahoo.co.uk> Message-ID: <61cb8e11-0441-6f4a-891e-7c5800391ead@yahoo.co.uk> On 08/05/2021 17:31, lejeczek wrote: > Hi guys. > > I'm experiencing a pretty weird wireguard, or perhaps > kernel/OS stack bits behavior. > > I have three nodes which all can ping each other on wg0's > IPs but when I add a secondary IP: > > -> $ ip addr add 10.0.0.226/24 dev wg0 > > it gets weird, namely, say when that sec IP is on > A -> B ping returns; C ping waits, no errors, no return > B -> both C & A pings return > C -> neither A nor B ping returns > > I'm on CentOS with 4.18.0-301.1.el8.x86_64. > All three nodes are virtually identical kvm VMs. > > any suggestions as to what is not working here or how to > troubleshoot are vey appreciated. > many thanks, L. > > > > What I've just noticed for the first time is, config eg.: .. [Peer] .. AllowedIPs = 10.0.0.2/32, 10.0.0.226/32 Endpoint = 10.1.1.224:51852 [Peer] .. AllowedIPs = 10.0.0.3/32, 10.0.0.226/32 Endpoint = 10.1.1.225:51853 > $ wg interface: wg0 ? public key: c+gJArxYd8+= ? private key: (hidden) ? listening port: 51851 peer: K/= ? preshared key: (hidden) ? endpoint: 10.1.1.225:51853 ? allowed ips: 10.0.0.3/32, 10.0.0.226/32 ? latest handshake: 16 seconds ago ? transfer: 124 B received, 2.14 KiB sent peer: /KidNfhqgP/+c3A= ? preshared key: (hidden) ? endpoint: 10.1.1.224:51852 ? allowed ips: 10.0.0.2/32??????????????? # !! no 10.0.0.226/32 ? ? latest handshake: 3 minutes, 15 seconds ago ? transfer: 180 B received, 92 B sent That is probably why only 10.0.0.3 with secondary IP is "reachable". Right? If that is by design and expected - why is that and how to make a "floating" IP work if that is by design? thanks, L. From rm at romanrm.net Sun May 9 07:52:36 2021 From: rm at romanrm.net (Roman Mamedov) Date: Sun, 9 May 2021 12:52:36 +0500 Subject: secondary IP on wg0 fails In-Reply-To: References: <204f6e7b-d594-c2c0-5242-1643055065c3.ref@yahoo.co.uk> <204f6e7b-d594-c2c0-5242-1643055065c3@yahoo.co.uk> <20210508215039.31f32aae@natsu> Message-ID: <20210509125236.17dd99aa@natsu> On Sat, 8 May 2021 19:49:06 +0100 lejeczek wrote: > > Also remember that sets of AllowedIPs should be unique within the network, > > i.e. can't have the same AllowedIPs or ranges listed for multiple nodes at the > > same time. Setting it to the same /24 on all nodes will not work. > > > > If still not clear, better post your complete config (without keys). > > > It's the same single subnet 10.0.0.0/24 and to reiterate - > wg0's "primary" IPs can all ping each other. > All nodes have, respectively: > eg. node-B > [peer] > ... > AllowedIPs = 10.0.0.1/32, 10.0.0.226/32 > Endpoint = 10.1.1.223:51851 > > [peer] > ... > AllowedIPs = 10.0.0.3/32, 10.0.0.226/32 > Endpoint = 10.1.1.225:51853 See above for "Also remember...", you cannot have 10.0.0.226/32 added to multiple peers as AllowedIPs at the same time. -- With respect, Roman From Jason at zx2c4.com Mon May 10 09:06:28 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 10 May 2021 11:06:28 +0200 Subject: Wintun - Requested GUID is already in use error on Windows 10 In-Reply-To: <000401d74418$ffecc590$ffc650b0$@glosol.com> References: <000b01d743f5$815d8fc0$8418af40$@glosol.com> <000401d74418$ffecc590$ffc650b0$@glosol.com> Message-ID: Thanks for the report. I think I understand what's going on. This will fix it: https://git.zx2c4.com/wintun/commit/?id=28888d254be9b499ac6a4b7f1c704cf46cca88f6 In the interim, you can just delete those windscribe interfaces I guess. From clint at openziti.org Mon May 10 11:21:27 2021 From: clint at openziti.org (Clint Dovholuk) Date: Mon, 10 May 2021 07:21:27 -0400 Subject: mechanism for wintun updates Message-ID: <2b73e539c3f0ae11bb68e2a7410a52b4@mail.gmail.com> Hi, I keep looking at the website for the latest wintun release - I see it's up to 0.10.5 now (last time I had checked was 0.10.3). Is there some way to provide some meta data/link to 'the latest' so that we can monitor wintun for updates, try them out and take 'the latest'? I don't care what the mechanism is, ideally it is something I could automate but even an email to this list that a release was put out would be better. If something like this exists already I'd love to be educated about it - if it's out there I've just not found it yet. Thanks -Clint From Jason at zx2c4.com Mon May 10 14:47:12 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 10 May 2021 16:47:12 +0200 Subject: mechanism for wintun updates In-Reply-To: <2b73e539c3f0ae11bb68e2a7410a52b4@mail.gmail.com> References: <2b73e539c3f0ae11bb68e2a7410a52b4@mail.gmail.com> Message-ID: Hi Clint, The cgit has an atom feed https://git.zx2c4.com/wintun/ and you can of course enumerate tags using the http dumb protocol: https://git.zx2c4.com/wintun/info/refs . The github mirror also has its own notification stuff. I could start sending [ANNOUNCE] emails for minor wintun updates, if you really think that's necessary, but so far, it seems like it's mostly a smaller group of developers using it. Jason From santiago at crfreenet.org Mon May 10 18:16:02 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Mon, 10 May 2021 20:16:02 +0200 Subject: [PATCH] sysdep/bsd: propagate OS-level IFF_MULTICAST to internal IF_MULTICAST flag In-Reply-To: <20210419222653.55983-1-toke@toke.dk> References: <20210419222653.55983-1-toke@toke.dk> Message-ID: On Tue, Apr 20, 2021 at 12:26:53AM +0200, Toke H?iland-J?rgensen wrote: > The BSD code did not propagate the OS-level IFF_MULTICAST flag to the > Bird-internal IF_MULTICAST flag, which causes problems with Wireguard > interfaces on FreeBSD. The Linux sysdep code does propagate the flag > already, so just copy over the same check and flag update. Thanks, merged. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From winfr34k at gmail.com Sun May 9 22:37:17 2021 From: winfr34k at gmail.com (Thomas Keppler) Date: Mon, 10 May 2021 00:37:17 +0200 Subject: WireGuard on macOS sets default route when it shouldn't Message-ID: <4686FAEA-B9C0-4897-8422-954AB84B4E78@gmail.com> Hello everyone, on a remote system I administer, I have setup a WireGuard VPN. All in all, this process has worked swimmingly. However, I have got one big issue on all of my macOS clients and I'm not sure if it's a bug or if it's me just using the software aka holding it wrong. I am not quite sure if this Mailing List is the right place to bother with questions like this, but I will try my luck anyways :-) Given a client configuration like so: ------------ 8< ------------ [Interface] PrivateKey = Address = 192.168.1.1/32 DNS = 192.168.0.253 MTU = 1420 [Peer] PublicKey = PresharedKey = AllowedIPs = 192.168.0.0/24, 192.168.1.254/32 Endpoint = :51820 ------------ >8 ------------ When I activate the tunnel connection, I always get several routes pushed, all of which are OK except the default route: ------------ 8< ------------ default via link#19 dev utun6 192.168.0.0/24 dev utun6 scope link 192.168.1.1/32 via 192.168.1.1 dev utun6 192.168.1.254/32 dev utun6 scope link 224.0.0.0/4 dev utun6 scope link 255.255.255.255/32 dev utun6 scope link ------------ >8 ------------ From what I have read so far on other forums, Reddit, StackOverflow and such, the specific "AllowedIPs" I'm supplying should prevent the default route from being pushed. I have also tried to locate the code responsible for pushing these routes, but so far I could only gather that a "routeSocket" is established and watched in the Go internals that seems to be only read. The macOS app also does not seem to modify this socket (or any part I have read so far). So given all of this, I have got two (main) questions (and an aside): 1.) Am I using WireGuard just plainly wrong or is it a Bug/Known Issue? 2.) Where is the code responsible for pushing routes? 3.) ...and what are good resources to check to get a better understanding of how this works internally? Thank you very much for any response to this message in advance. I cannot wait to figure this one out! -- Sincerely Thomas Keppler From leeloored at gmx.com Mon May 10 11:40:36 2021 From: leeloored at gmx.com (Kent Friis) Date: Mon, 10 May 2021 13:40:36 +0200 Subject: mechanism for wintun updates In-Reply-To: <2b73e539c3f0ae11bb68e2a7410a52b4@mail.gmail.com> Message-ID: <20210510134036.ea080143a0cfbe58903c7866@gmx.com> > I keep looking at the website for the latest wintun release - I see it's > up to 0.10.5 now (last time I had checked was 0.10.3). Is there some way > to provide some meta data/link to 'the latest' so that we can monitor > wintun for updates, try them out and take 'the latest'? > I don't care what the mechanism is, ideally it is something I could > automate but even an email to this list that a release was put out would > be better. > If something like this exists already I'd love to be educated about it - > if it's out there I've just not found it yet. How about RSS? feed:https://github.com/WireGuard/wintun/tags.atom From Jason at zx2c4.com Tue May 11 11:37:25 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Tue, 11 May 2021 13:37:25 +0200 Subject: Wintun - Requested GUID is already in use error on Windows 10 In-Reply-To: References: <000b01d743f5$815d8fc0$8418af40$@glosol.com> <000401d74418$ffecc590$ffc650b0$@glosol.com> Message-ID: Hi Piotr, Can you update to the wg4win version I just released and let me know if the problem goes away? Thanks, Jason From sascha.dierberg at gmail.com Tue May 11 13:29:11 2021 From: sascha.dierberg at gmail.com (Sascha Dierberg) Date: Tue, 11 May 2021 15:29:11 +0200 Subject: [PATCH] Windows Bindings: handler for WSAEMSGSIZE added to avoid stop receiving data In-Reply-To: References: Message-ID: Hello Jason, your bugfix works fine for jumbo packets but not if the Windows socket is flooded with " nc -u < /dev/urandom ". best regards - Sascha Am Di., 27. Apr. 2021 um 04:10 Uhr schrieb Jason A. Donenfeld : > > Thanks for the patch. That's a nice bug you found. > > I fixed things slightly differently, but mentioned you in the commit: > https://git.zx2c4.com/wireguard-go/commit/?id=8246d251ea9b9cbef07082bd69280a8f988cec0c -- Sascha Dierberg Karl-Marx-Allee 61 D-10243 Berlin mailto:sascha at dierberg.de Phone: +49 178 3727242 Fax: +49 30 42019631 From piotrs at glosol.com Tue May 11 14:25:39 2021 From: piotrs at glosol.com (Piotr Sobczak) Date: Tue, 11 May 2021 16:25:39 +0200 Subject: Wintun - Requested GUID is already in use error on Windows 10 In-Reply-To: References: <000b01d743f5$815d8fc0$8418af40$@glosol.com> <000401d74418$ffecc590$ffc650b0$@glosol.com> Message-ID: Hi Jason, It looks like the same error still occurs with version 0.3.14. Let me know if you need any additional information or if you would like me to try anything else. Thanks, Piotr On Tue, May 11, 2021 at 1:37 PM Jason A. Donenfeld wrote: > > Hi Piotr, > > Can you update to the wg4win version I just released and let me know > if the problem goes away? > > Thanks, > Jason From Jason at zx2c4.com Tue May 11 14:49:13 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Tue, 11 May 2021 16:49:13 +0200 Subject: [PATCH] Windows Bindings: handler for WSAEMSGSIZE added to avoid stop receiving data In-Reply-To: References: Message-ID: Hi Sascha, Oh, boy, that's embarrassing. Fixed here: https://git.zx2c4.com/wireguard-go/commit/?id=5846b622837e04dbc35b153d9ceda7fd66397520 Thanks again for the report. Jason From Jason at zx2c4.com Tue May 11 17:53:52 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Tue, 11 May 2021 19:53:52 +0200 Subject: Wintun - Requested GUID is already in use error on Windows 10 In-Reply-To: References: <000b01d743f5$815d8fc0$8418af40$@glosol.com> <000401d74418$ffecc590$ffc650b0$@glosol.com> Message-ID: Hi Piotr, Thanks for the feedback. I sent you a message offlist with a custom build containing https://git.zx2c4.com/wintun/commit/?id=479bbdc50a45ca9ae62ac15a1ee7445a6cbbe42a . Waiting for your feedback on it. Thanks, Jason From piotrs at glosol.com Tue May 11 18:07:10 2021 From: piotrs at glosol.com (Piotr Sobczak) Date: Tue, 11 May 2021 20:07:10 +0200 Subject: Wintun - Requested GUID is already in use error on Windows 10 In-Reply-To: References: <000b01d743f5$815d8fc0$8418af40$@glosol.com> <000401d74418$ffecc590$ffc650b0$@glosol.com> Message-ID: Hi Jason, It worked. I replied to your other email with the full log as you requested. Thank you for your help with this! Piotr On Tue, May 11, 2021 at 7:54 PM Jason A. Donenfeld wrote: > > Hi Piotr, > > Thanks for the feedback. I sent you a message offlist with a custom > build containing > https://git.zx2c4.com/wintun/commit/?id=479bbdc50a45ca9ae62ac15a1ee7445a6cbbe42a > . Waiting for your feedback on it. > > Thanks, > Jason From raoul.bhatia at radarcs.com Wed May 12 05:19:48 2021 From: raoul.bhatia at radarcs.com (Raoul Bhatia) Date: Wed, 12 May 2021 05:19:48 +0000 Subject: Wireguard connection lost between peers Message-ID: <1CCB5519-611B-4377-97A9-0F9179E3C6F2@radarcs.com> Hi Jason Apologies for taking some time to get back to you. We tried to verify a few things and to see if we spot anything unusual, and waited for a few mor instances to happen to get sufficient right data. > That's surprising behavior. Thanks for debugging it. Can you see if > you can reproduce with dynamic logging enabled? That'll give some > useful information in dmesg: > > # modprobe wireguard && echo module wireguard +p > > /sys/kernel/debug/dynamic_debug/control I did enable the debug control and also set sysctl -w net.core.message_cost=0 and have extracted a sample of the issue. Please find it here https://nem3d.net/wireguard_20210512a.txt From my observation, it is always the following symptoms: 1. Everything is WORKING: LXC container d1-h sends handshake initiation. Host wg0 receives, re-creates keypair, answers d1-h receives, re-creates keypair, sends keepalive wg0 receives keepalive etc. 2. Somewhen it BREAKS d1-h stopps hearing back after 15 seconds. Initialization loop like mentioned above d1-h stopps hearing back after 15 seconds. etc. As mentioned, the resolution is to dump the config, remove the peer, and syncconf to restore. This time, I used "nsenter -n" to apply this procedure to the unprivileged container interface d1-h. Lastly, we also saw similar behavior even between 2 physical hosts. I will try to gather similar debug information. Please let me know if further information is needed to better understand the problem. Raoul -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6069 bytes Desc: not available URL: From burkett.andrew at gmail.com Thu May 13 23:18:01 2021 From: burkett.andrew at gmail.com (Andrew Burkett) Date: Thu, 13 May 2021 16:18:01 -0700 Subject: wireguard.exe no MessageBox option? Message-ID: Would it be possible to add an option to wireguard.exe to output the return message for the /install* and /uninstall* commands either to stdout/stderr or a logfile? It would make it a bit easier to script installation/management to not have to worry about a MessageBox popping up with an error. Thanks for the great software. Andrew From jonny at lemonjuice.tk Fri May 14 15:15:58 2021 From: jonny at lemonjuice.tk (Jonny Proud) Date: Fri, 14 May 2021 16:15:58 +0100 Subject: wireguard.exe no MessageBox option? In-Reply-To: References: Message-ID: <8aa62767-1d62-29ca-cc1a-d5bb9511e7bf@lemonjuice.tk> Hi Andrew, This would be a great idea for deployments using SCCM or SCCM like tools. It would be best if the installer had a silent install argument (/silent), and then depending on the outcome of the install would change the exit code of the process. Then you can check the returned exit code from the installer process. Example codes; 0 - Successful 1 - Known Error 1 2 - Known Error 2 3010 - A reboot is required to complete the install. and so on. Then a /log "c:\path\to\file.log" argument to output the installation log Jonny Proud On 14/05/2021 00:18, Andrew Burkett wrote: > Would it be possible to add an option to wireguard.exe to output the > return message for the /install* and /uninstall* commands either to > stdout/stderr or a logfile? It would make it a bit easier to script > installation/management to not have to worry about a MessageBox > popping up with an error. > > Thanks for the great software. > > Andrew > From Jason at zx2c4.com Mon May 17 09:43:31 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 17 May 2021 11:43:31 +0200 Subject: [PATCH RESEND wireguard-tools] contrib/launchd: fix xml syntax error In-Reply-To: <20210517081730.868755-1-liuhangbin@gmail.com> References: <20210517081730.868755-1-liuhangbin@gmail.com> Message-ID: Applied, thanks. From Jason at zx2c4.com Mon May 17 09:44:08 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 17 May 2021 11:44:08 +0200 Subject: [PATCH wireguard-tools] src/show: remove dead offset check code In-Reply-To: <20210517091053.886157-1-liuhangbin@gmail.com> References: <20210517091053.886157-1-liuhangbin@gmail.com> Message-ID: The compiler will optimize this out, right? In which case, I like the consistency, in case lines are ever reordered or copy and pasted. From Jason at zx2c4.com Mon May 17 15:07:12 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 17 May 2021 17:07:12 +0200 Subject: wireguard.exe no MessageBox option? In-Reply-To: References: Message-ID: Hi Andrew, It's a bit tricky, because UI apps are treated differently than console apps: cmd.exe won't wait for them to complete, and they get empty stdio handles. But I've used the latter property to detect what's up and hopefully achieve some kind of compromise. Let me know if this commit does the trick: https://git.zx2c4.com/wireguard-windows/commit/?id=ed59b1b2e834b6d35b11bab63551b21bc60d7f35 Basically, if stderr is available, logs go there. Otherwise if stdout is available, logs go there. Otherwise errors show in a message box. So this should allow you to do things like: wireguard /installtunnelservice ... 2>C:\path\to\log.txt Jason From michael.apply at gmail.com Sat May 15 17:36:33 2021 From: michael.apply at gmail.com (Michael Wu) Date: Sun, 16 May 2021 01:36:33 +0800 Subject: Bug report: Policy routed packets are dropped by wireguard Message-ID: Hello, I'd like to confirm that the following problem seemed to be a bug, and not configuration error: https://lists.zx2c4.com/pipermail/wireguard/2019-September/004545.html (Content dupated at the end of this email for easier reference) On system 1 (kernel 4.15), everything worked as expected. However, on system 2 (kernel 5.4), the issue described above is observed. Regards, Michael [System 1]: Ubuntu 18.04.5 LTS 4.15.0-128-generic #131-Ubuntu SMP Wed Dec 9 06:57:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux [System 2]: Ubuntu 20.04.2 LTS 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:39:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux [Policy routed packets are dropped by wireguard] Original mail: https://lists.zx2c4.com/pipermail/wireguard/2019-September/004545.html Hello! I'm looking for technical advice. Currently I'm trying to pass marked sessions through wireguard VPN network. Marking is done by cgroups classid matching: > iptables -A OUTPUT -m cgroup --cgroup 3735928559 -j MARK --set-xmark 0x1c3/0xffffffff The only route in the `vpn` table is default routing through wg0: > ip route add default dev wg0 table vpn Routing rule is pretty simple: > ip rule add fwmark 451 table vpn Now I pass some packets on the interface: > cgexec -g net_cls:vpn ping 10.0.1.1 I see packets reaching interface but dropped in the driver: > tcpdump -i wg0 host 10.0.1.1 > ... > 6 packets dropped by interface Value in 4th column (TX drop) is increasing in the `/proc/net/dev` for wg0. If I add route to default routing table and do ping without assigning cgroup to the process then all is perfectly fine. > ip route add 10.0.1.0/24 dev wg0 > ping 10.0.1.1 > PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data. > 64 bytes from 10.0.1.1: icmp_seq=1 ttl=64 time=46.1 ms Is it some kind of a bug of misconfiguration? > uname -r > 5.2.1-gentoo Installed Gentoo package atom. > =net-vpn/wireguard-0.0.20190913 Thanks for any help! From max.schulze at online.de Sun May 16 12:07:13 2021 From: max.schulze at online.de (Max Schulze) Date: Sun, 16 May 2021 14:07:13 +0200 Subject: wireguard-windows: Tunnel shown as active but never completed handshake Message-ID: I am puzzled that the wireguard management UI shows "active", even though the tunnel is not established. I know for sure the peer is reachable via ping, but does not have wireguard running. I am reproducing an issue where the peer went down but the tunnel on the client kept being displayed as "active". Wouldn't it be better to show 'tunnel up - handshake in progress' or something similar and only switch to 'active' once there has been an handshake? Can I provide more debug info? Note: the wintun errors are there even when it works - I might report a separate Issue for them... Best regards, max C:\Windows\system32>wg interface: <> ? public key: QhK0= ? private key: (hidden) ? listening port: 65170 peer: 9npne1CDg= ? endpoint: 192.168.3.184:51820 ? allowed ips: 192.168.223.0/24 ? transfer: 0 B received, 10.12 KiB sent ? persistent keepalive: every 20 seconds 2021-05-15 18:34:53.501802: [MGR] [Wintun] WintunEnumAdapters: Failed to create adapter 2276 data 2021-05-16 13:48:04.114000: [TUN] [<>] Starting WireGuard/0.3.14 (Windows 6.1.7601; amd64) 2021-05-16 13:48:04.114000: [TUN] [<>] Watching network interfaces 2021-05-16 13:48:04.114000: [TUN] [<>] Resolving DNS names 2021-05-16 13:48:04.114000: [TUN] [<>] Creating Wintun interface 2021-05-16 13:48:04.114000: [TUN] [<>] [Wintun] GetNetCfgInstanceIdFromDevInfo: Opening adapter 2276 device registry key failed: Der angeforderte Ger?teregistrierungsschl?ssel ist nicht vorhanden. (Code 0xE0000204) 2021-05-16 13:48:04.114000: [TUN] [<>] [Wintun] CreateAdapter: Creating adapter 2021-05-16 13:48:04.198000: [TUN] [<>] [Wintun] SelectDriver: Using existing driver 0.11 2021-05-16 13:48:04.660000: [TUN] [<>] Using Wintun/0.11 2021-05-16 13:48:04.660000: [TUN] [<>] Enabling firewall rules 2021-05-16 13:48:04.670000: [TUN] [<>] Dropping privileges 2021-05-16 13:48:04.670000: [TUN] [<>] Creating interface instance 2021-05-16 13:48:04.680000: [TUN] [<>] Setting interface configuration 2021-05-16 13:48:04.680000: [TUN] [<>] UAPI: Updating private key 2021-05-16 13:48:04.680000: [TUN] [<>] UAPI: Removing all peers 2021-05-16 13:48:04.680000: [TUN] [<>] peer(9npn?+CDg) - UAPI: Created 2021-05-16 13:48:04.680000: [TUN] [<>] peer(9npn?+CDg) - UAPI: Updating endpoint 2021-05-16 13:48:04.680000: [TUN] [<>] peer(9npn?+CDg) - UAPI: Updating persistent keepalive interval 2021-05-16 13:48:04.680000: [TUN] [<>] peer(9npn?+CDg) - UAPI: Removing all allowedips 2021-05-16 13:48:04.680000: [TUN] [<>] peer(9npn?+CDg) - UAPI: Adding allowedip 2021-05-16 13:48:04.680000: [TUN] [<>] Bringing peers up 2021-05-16 13:48:04.681000: [TUN] [<>] UDP bind has been updated 2021-05-16 13:48:04.681000: [TUN] [<>] peer(9npn?+CDg) - Starting 2021-05-16 13:48:04.681000: [TUN] [<>] peer(9npn?+CDg) - Sending keepalive packet 2021-05-16 13:48:04.681000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:48:04.681000: [TUN] [<>] peer(9npn?+CDg) - Routine: sequential receiver - started 2021-05-16 13:48:04.681000: [TUN] [<>] Routine: encryption worker 1 - started 2021-05-16 13:48:04.681000: [TUN] [<>] Routine: decryption worker 1 - started 2021-05-16 13:48:04.681000: [TUN] [<>] Routine: handshake worker 1 - started 2021-05-16 13:48:04.681000: [TUN] [<>] Routine: encryption worker 2 - started 2021-05-16 13:48:04.681000: [TUN] [<>] Routine: decryption worker 2 - started 2021-05-16 13:48:04.681000: [TUN] [<>] Routine: handshake worker 2 - started 2021-05-16 13:48:04.681000: [TUN] [<>] Routine: encryption worker 3 - started 2021-05-16 13:48:04.681000: [TUN] [<>] Routine: decryption worker 3 - started 2021-05-16 13:48:04.681000: [TUN] [<>] Routine: handshake worker 3 - started 2021-05-16 13:48:04.681000: [TUN] [<>] Routine: encryption worker 4 - started 2021-05-16 13:48:04.681000: [TUN] [<>] Routine: decryption worker 4 - started 2021-05-16 13:48:04.681000: [TUN] [<>] Routine: handshake worker 4 - started 2021-05-16 13:48:04.681000: [TUN] [<>] Routine: TUN reader - started 2021-05-16 13:48:04.687000: [TUN] [<>] Routine: event worker - started 2021-05-16 13:48:04.687000: [TUN] [<>] Interface state was Down, requested Up, now Up 2021-05-16 13:48:04.687000: [TUN] [<>] Monitoring default v4 routes 2021-05-16 13:48:04.687000: [TUN] [<>] Binding v4 socket to interface 11 (blackhole=false) 2021-05-16 13:48:04.689000: [TUN] [<>] Routine: receive incoming v6 - started 2021-05-16 13:48:04.689000: [TUN] [<>] Routine: receive incoming v4 - started 2021-05-16 13:48:04.689000: [TUN] [<>] peer(9npn?+CDg) - Routine: sequential sender - started 2021-05-16 13:48:04.691000: [TUN] [<>] Setting device v4 addresses 2021-05-16 13:48:04.752000: [TUN] [<>] Monitoring default v6 routes 2021-05-16 13:48:04.752000: [TUN] [<>] Binding v6 socket to interface 0 (blackhole=false) 2021-05-16 13:48:04.752000: [TUN] [<>] Setting device v6 addresses 2021-05-16 13:48:04.822000: [TUN] [<>] Listening for UAPI requests 2021-05-16 13:48:04.822000: [TUN] [<>] Startup complete 2021-05-16 13:48:09.957000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:48:09.957000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:48:13.991000: [MGR] [Wintun] CreateAdapterData: Opening adapter 2276 device registry key failed: Der angeforderte Ger?teregistrierungsschl?ssel ist nicht vorhanden. (Code 0xE0000204) 2021-05-16 13:48:13.991000: [MGR] [Wintun] WintunEnumAdapters: Failed to create adapter 2276 data 2021-05-16 13:48:15.126000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:48:15.126000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:48:20.407000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:48:20.407000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:48:25.584000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:48:25.584000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:48:30.842000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:48:30.842000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:48:36.044000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:48:41.132000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:48:41.132000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:48:46.324000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:48:51.464000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:48:51.464000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:48:56.605000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:48:56.605000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:49:01.854000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:49:06.975000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:49:12.056000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:49:12.056000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:49:17.165000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:49:17.165000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:49:22.242000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:49:22.242000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:49:27.340000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:49:27.340000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:49:32.355000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 3) 2021-05-16 13:49:32.355000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:49:37.450000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:49:37.450000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:49:42.531000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:49:42.531000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:49:47.840000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:49:47.840000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:49:53.065000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:49:53.065000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:49:58.275000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:50:03.341000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:50:03.341000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:50:08.626000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:50:08.626000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:50:13.946000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 3) 2021-05-16 13:50:13.946000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:50:19.156000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 4) 2021-05-16 13:50:19.156000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:50:24.287000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 5) 2021-05-16 13:50:24.287000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:50:29.350000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 6) 2021-05-16 13:50:29.350000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:50:34.640000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 7) 2021-05-16 13:50:34.640000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:50:39.912000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 8) 2021-05-16 13:50:39.912000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:50:45.153000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 9) 2021-05-16 13:50:45.153000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:50:50.245000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 10) 2021-05-16 13:50:50.245000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:50:55.309000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 11) 2021-05-16 13:50:55.309000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:51:00.553000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 12) 2021-05-16 13:51:00.553000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:51:05.714000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 13) 2021-05-16 13:51:05.714000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:51:10.835000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 14) 2021-05-16 13:51:10.835000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:51:15.996000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 15) 2021-05-16 13:51:15.996000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:51:21.221000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 16) 2021-05-16 13:51:21.221000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:51:26.417000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 17) 2021-05-16 13:51:26.417000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:51:31.673000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:51:31.673000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:51:36.739000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 3) 2021-05-16 13:51:36.739000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:51:41.796000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 4) 2021-05-16 13:51:41.796000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:51:46.865000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:51:46.865000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:51:51.969000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 3) 2021-05-16 13:51:51.969000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:51:57.275000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 4) 2021-05-16 13:51:57.275000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:52:02.465000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 5) 2021-05-16 13:52:02.465000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:52:07.777000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 6) 2021-05-16 13:52:07.777000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:52:12.994000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 7) 2021-05-16 13:52:12.994000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:52:18.219000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 8) 2021-05-16 13:52:18.219000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:52:23.398000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 9) 2021-05-16 13:52:23.398000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:52:28.674000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 10) 2021-05-16 13:52:28.674000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:52:33.856000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 11) 2021-05-16 13:52:33.856000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:52:39.128000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 12) 2021-05-16 13:52:39.128000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:52:44.265000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 13) 2021-05-16 13:52:44.265000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:52:49.490000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 14) 2021-05-16 13:52:49.490000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:52:54.761000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 15) 2021-05-16 13:52:54.761000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:52:59.766000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation 2021-05-16 13:53:04.937000: [TUN] [<>] peer(9npn?+CDg) - Handshake did not complete after 5 seconds, retrying (try 2) 2021-05-16 13:53:04.937000: [TUN] [<>] peer(9npn?+CDg) - Sending handshake initiation From liuhangbin at gmail.com Mon May 17 03:29:23 2021 From: liuhangbin at gmail.com (Hangbin Liu) Date: Mon, 17 May 2021 11:29:23 +0800 Subject: [PATCH] contrib/launchd: fix xml syntax error Message-ID: <20210517032923.786658-1-liuhangbin@gmail.com> The current plist xml gets error "DOCTYPE improperly terminated" with xml syntax checker[1]. The example in apple doc[2] also doesn't have semicolon at the end of DOCTYPE line. [1] https://www.w3schools.com/xml/xml_validator.asp [2] https://opensource.apple.com/source/launchd/launchd-257/launchd/doc/HOWTO.html Fixes: b30e74b5956a ("wg-quick: darwin: support being called from launchd") Signed-off-by: Hangbin Liu --- contrib/launchd/com.wireguard.wg0.plist | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/launchd/com.wireguard.wg0.plist b/contrib/launchd/com.wireguard.wg0.plist index 9fc0141..ea1eab6 100644 --- a/contrib/launchd/com.wireguard.wg0.plist +++ b/contrib/launchd/com.wireguard.wg0.plist @@ -1,5 +1,5 @@ - + Label -- 2.26.3 From liuhangbin at gmail.com Mon May 17 08:17:30 2021 From: liuhangbin at gmail.com (Hangbin Liu) Date: Mon, 17 May 2021 16:17:30 +0800 Subject: [PATCH RESEND wireguard-tools] contrib/launchd: fix xml syntax error Message-ID: <20210517081730.868755-1-liuhangbin@gmail.com> The current plist xml gets error "DOCTYPE improperly terminated" with xml syntax checker[1]. The example in apple doc[2] also doesn't have semicolon at the end of DOCTYPE line. [1] https://www.w3schools.com/xml/xml_validator.asp [2] https://opensource.apple.com/source/launchd/launchd-257/launchd/doc/HOWTO.html Fixes: b30e74b5956a ("wg-quick: darwin: support being called from launchd") Signed-off-by: Hangbin Liu --- contrib/launchd/com.wireguard.wg0.plist | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/launchd/com.wireguard.wg0.plist b/contrib/launchd/com.wireguard.wg0.plist index 9fc0141..ea1eab6 100644 --- a/contrib/launchd/com.wireguard.wg0.plist +++ b/contrib/launchd/com.wireguard.wg0.plist @@ -1,5 +1,5 @@ - + Label -- 2.26.3 From liuhangbin at gmail.com Mon May 17 09:10:53 2021 From: liuhangbin at gmail.com (Hangbin Liu) Date: Mon, 17 May 2021 17:10:53 +0800 Subject: [PATCH wireguard-tools] src/show: remove dead offset check code Message-ID: <20210517091053.886157-1-liuhangbin@gmail.com> At first the offset will always be 0. So the check of offset ? ", " : "" is useless. Signed-off-by: Hangbin Liu --- src/show.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/show.c b/src/show.c index 761858b..83d4d6b 100644 --- a/src/show.c +++ b/src/show.c @@ -141,7 +141,7 @@ static size_t pretty_time(char *buf, const size_t len, unsigned long long left) seconds = left % 60; if (years) - offset += snprintf(buf + offset, len - offset, "%s%llu " TERMINAL_FG_CYAN "year%s" TERMINAL_RESET, offset ? ", " : "", years, years == 1 ? "" : "s"); + offset = snprintf(buf, len, "%llu " TERMINAL_FG_CYAN "year%s" TERMINAL_RESET, years, years == 1 ? "" : "s"); if (days) offset += snprintf(buf + offset, len - offset, "%s%llu " TERMINAL_FG_CYAN "day%s" TERMINAL_RESET, offset ? ", " : "", days, days == 1 ? "" : "s"); if (hours) -- 2.26.3 From liuhangbin at gmail.com Tue May 18 01:01:12 2021 From: liuhangbin at gmail.com (Hangbin Liu) Date: Tue, 18 May 2021 09:01:12 +0800 Subject: [PATCH wireguard-tools] src/show: remove dead offset check code In-Reply-To: References: <20210517091053.886157-1-liuhangbin@gmail.com> Message-ID: On Mon, May 17, 2021 at 11:44:08AM +0200, Jason A. Donenfeld wrote: > The compiler will optimize this out, right? In which case, I like the > consistency, in case lines are ever reordered or copy and pasted. Not sure if compiler will optimize. I just got the complain when do covscan checking. I'm OK to keep the format. Thanks Hangbin From Jason at zx2c4.com Tue May 18 07:14:15 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Tue, 18 May 2021 09:14:15 +0200 Subject: [PATCH wireguard-tools] src/show: remove dead offset check code In-Reply-To: References: <20210517091053.886157-1-liuhangbin@gmail.com> Message-ID: Looks like the compiler optimizes it: https://data.zx2c4.com/the-compiler-optimizes-the-first-addition.png From Jason at zx2c4.com Tue May 18 15:01:14 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Tue, 18 May 2021 17:01:14 +0200 Subject: Bug report: Policy routed packets are dropped by wireguard In-Reply-To: References: Message-ID: Hi, On Mon, May 17, 2021 at 5:22 PM Michael Wu wrote: > I'd like to confirm that the following problem seemed to be a bug, and > not configuration error: > https://lists.zx2c4.com/pipermail/wireguard/2019-September/004545.html > (Content dupated at the end of this email for easier reference) > > On system 1 (kernel 4.15), everything worked as expected. However, on > system 2 (kernel 5.4), the issue described above is observed. > > Regards, > Michael > > > [System 1]: > Ubuntu 18.04.5 LTS > 4.15.0-128-generic #131-Ubuntu SMP Wed Dec 9 06:57:35 UTC 2020 x86_64 > x86_64 x86_64 GNU/Linux > > [System 2]: > Ubuntu 20.04.2 LTS > 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:39:42 UTC 2021 x86_64 > x86_64 x86_64 GNU/Linux > > [Policy routed packets are dropped by wireguard] > Original mail: https://lists.zx2c4.com/pipermail/wireguard/2019-September/004545.html > > Hello! > > I'm looking for technical advice. > Currently I'm trying to pass marked sessions through wireguard VPN network. > > Marking is done by cgroups classid matching: > > iptables -A OUTPUT -m cgroup --cgroup 3735928559 -j MARK --set-xmark 0x1c3/0xffffffff > > The only route in the `vpn` table is default routing through wg0: > > ip route add default dev wg0 table vpn > > Routing rule is pretty simple: > > ip rule add fwmark 451 table vpn > > Now I pass some packets on the interface: > > cgexec -g net_cls:vpn ping 10.0.1.1 > > I see packets reaching interface but dropped in the driver: > > tcpdump -i wg0 host 10.0.1.1 > > ... > > 6 packets dropped by interface > > Value in 4th column (TX drop) is increasing in the `/proc/net/dev` for wg0. > > If I add route to default routing table and do ping without assigning > cgroup to the process then all is perfectly fine. > > ip route add 10.0.1.0/24 dev wg0 > > > ping 10.0.1.1 > > PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data. > > 64 bytes from 10.0.1.1: icmp_seq=1 ttl=64 time=46.1 ms > > Is it some kind of a bug of misconfiguration? I think I might have fixed this upstream in October: https://git.zx2c4.com/wireguard-linux/commit/?id=46d6c5ae953cc0be38efd0e469284df7c4328cf8 I suspect that this patch needs to be in your kernel in order for the bug to go away. I added a "warn-only" test to the compat layer here: https://git.zx2c4.com/wireguard-linux-compat/commit/?id=99e954f4871d9a760451c5ada99dfaae5df256e5 These are tested on all the Ubuntu kernels. Looking at those here and ctrl+f-ing for the warning message on https://www.wireguard.com/build-status/#data-wireguard-linux-compat we can see which ones are still unpatched: - 5.4.0-74.83-ubuntu-focal: good - 5.4.0-74.83~18.04.1-ubuntu-bionic-hwe-5.4: good - 5.3.0-74.70-ubuntu-bionic-hwe: BAD - 4.15.0-144.148-ubuntu-bionic: good So it looks like, of the most recent Canonical kernels, only their 5.3 is missing the patch, but their 4.15 and 5.4 trees are working fine. So I'd assume the problem is that the 5.4 kernel you're running is old and needs an update? Or perhaps you've unearthed a different problem? But please make sure you're running 5.4.0-74.83 first, and then let me know. Thanks, Jason From syzbot+a70a6358abd2c3f9550f at syzkaller.appspotmail.com Wed May 19 17:35:20 2021 From: syzbot+a70a6358abd2c3f9550f at syzkaller.appspotmail.com (syzbot) Date: Wed, 19 May 2021 10:35:20 -0700 Subject: [syzbot] BUG: MAX_LOCKDEP_KEYS too low! (2) Message-ID: <0000000000003687bd05c2b2401d@google.com> Hello, syzbot found the following issue on: HEAD commit: b81ac784 net: cdc_eem: fix URL to CDC EEM 1.0 spec git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=15a257c3d00000 kernel config: https://syzkaller.appspot.com/x/.config?x=5b86a12e0d1933b5 dashboard link: https://syzkaller.appspot.com/bug?extid=a70a6358abd2c3f9550f Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+a70a6358abd2c3f9550f at syzkaller.appspotmail.com BUG: MAX_LOCKDEP_KEYS too low! turning off the locking correctness validator. CPU: 0 PID: 5917 Comm: syz-executor.4 Not tainted 5.12.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 register_lock_class.cold+0x14/0x19 kernel/locking/lockdep.c:1281 __lock_acquire+0x102/0x5230 kernel/locking/lockdep.c:4781 lock_acquire kernel/locking/lockdep.c:5512 [inline] lock_acquire+0x1ab/0x740 kernel/locking/lockdep.c:5477 flush_workqueue+0x110/0x13e0 kernel/workqueue.c:2786 drain_workqueue+0x1a5/0x3c0 kernel/workqueue.c:2951 destroy_workqueue+0x71/0x800 kernel/workqueue.c:4382 alloc_workqueue+0xc40/0xef0 kernel/workqueue.c:4343 wg_newlink+0x43d/0x9e0 drivers/net/wireguard/device.c:335 __rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3452 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3500 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5562 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665d9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fb25febe188 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000056c0b0 RCX: 00000000004665d9 RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000005 RBP: 00000000004bfcb9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c0b0 R13: 00007fff30a5021f R14: 00007fb25febe300 R15: 0000000000022000 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller at googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. From vicencb at gmail.com Tue May 18 11:22:31 2021 From: vicencb at gmail.com (Vicente Bergas) Date: Tue, 18 May 2021 13:22:31 +0200 Subject: lost connection on dynamic IP Message-ID: Hi, i've got the following setup: A server connected to the Internet through an ISP that provides a dynamic IP with NAT. The server keeps the DNS updated with https://github.com/troglobit/inadyn A client on a tiny embedded board connects to the server by means of its domain name. Wireguard configurations are: # server/etc/wireguard/wg0.conf [Interface] ListenPort = port_number PrivateKey = ... [Peer] PublicKey = ... PresharedKey = ... PersistentKeepalive = 25 AllowedIPs = 10.0.0.2 # client/etc/wireguard/wg0.conf [Interface] PrivateKey = ... [Peer] PublicKey = ... PresharedKey = ... Endpoint = domain.name.that.resolves.to.a.dynamic.ip:port_number PersistentKeepalive = 25 AllowedIPs = 10.0.0.1 The server almost never initiates comunications towards the client. The client sends one packet every minute towards the server. I think the issue happens when the ISP on the server side shuts down the Internet connection for more than 1 hour! Then, it is restored with a new IP. inadyn detects the new IP and updates the DNS. At this point the Internet connection is operational again, but the client remains disconnected until rebooted. Is this scenario expected to work due to the "Built-in Roaming" ? Regards, Vicen?. From rm at romanrm.net Wed May 19 18:43:10 2021 From: rm at romanrm.net (Roman Mamedov) Date: Wed, 19 May 2021 23:43:10 +0500 Subject: lost connection on dynamic IP In-Reply-To: References: Message-ID: <20210519234310.66ea294e@natsu> On Tue, 18 May 2021 13:22:31 +0200 Vicente Bergas wrote: > A server connected to the Internet through an ISP that provides a > dynamic IP with NAT. If it's NAT, then your server has no dedicated public IP? What do you update to DNS, IP of the ISP's NAT pool (shared IP with many other customers)? > I think the issue happens when the ISP on the server side shuts down > the Internet connection for more than 1 hour! Then, it is restored > with a new IP. > inadyn detects the new IP and updates the DNS. > At this point the Internet connection is operational again, but the > client remains disconnected until rebooted. > > Is this scenario expected to work due to the "Built-in Roaming" ? It might work, helped by PersistentKeepalive, and as long as the server and the client don't change their IPs/ports *at the same time*. To protect against that, or to improve resiliency in general (and assuming there's actually no NAT at the server side after all), your client should resolve the DNS record for the server periodically, and in case the IP changed, call "wg set [interface] peer [key] endpoint [IP:port]". -- With respect, Roman From dvyukov at google.com Wed May 19 19:48:55 2021 From: dvyukov at google.com (Dmitry Vyukov) Date: Wed, 19 May 2021 21:48:55 +0200 Subject: [syzbot] BUG: MAX_LOCKDEP_KEYS too low! (2) In-Reply-To: <0000000000003687bd05c2b2401d@google.com> References: <0000000000003687bd05c2b2401d@google.com> Message-ID: On Wed, May 19, 2021 at 7:35 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit: b81ac784 net: cdc_eem: fix URL to CDC EEM 1.0 spec > git tree: net > console output: https://syzkaller.appspot.com/x/log.txt?x=15a257c3d00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=5b86a12e0d1933b5 > dashboard link: https://syzkaller.appspot.com/bug?extid=a70a6358abd2c3f9550f > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+a70a6358abd2c3f9550f at syzkaller.appspotmail.com > > BUG: MAX_LOCKDEP_KEYS too low! What config controls this? I don't see "MAX_LOCKDEP_KEYS too low" in any of the config descriptions... Here is what syzbot used: CONFIG_LOCKDEP=y CONFIG_LOCKDEP_BITS=16 CONFIG_LOCKDEP_CHAINS_BITS=17 CONFIG_LOCKDEP_STACK_TRACE_BITS=20 CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14 CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12 We already bumped most of these. The log contains dump of the lockdep debug files, is there any offender? Also looking at the log I noticed a memory safety bug in lockdep implementation: [ 2023.605505][ T6807] ================================================================== [ 2023.613589][ T6807] BUG: KASAN: global-out-of-bounds in print_name+0x1b0/0x1d0 [ 2023.624553][ T6807] Read of size 8 at addr ffffffff90225cb0 by task cat/6807 [ 2023.631765][ T6807] [ 2023.634096][ T6807] CPU: 1 PID: 6807 Comm: cat Not tainted 5.12.0-syzkaller #0 [ 2023.641488][ T6807] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 [ 2023.651745][ T6807] Call Trace: [ 2023.655031][ T6807] dump_stack+0x141/0x1d7 [ 2023.659375][ T6807] ? print_name+0x1b0/0x1d0 [ 2023.663890][ T6807] print_address_description.constprop.0.cold+0x5/0x2f8 [ 2023.670895][ T6807] ? print_name+0x1b0/0x1d0 [ 2023.675413][ T6807] ? print_name+0x1b0/0x1d0 [ 2023.679948][ T6807] kasan_report.cold+0x7c/0xd8 [ 2023.684725][ T6807] ? print_name+0x1b0/0x1d0 [ 2023.689248][ T6807] print_name+0x1b0/0x1d0 [ 2023.694196][ T6807] ? lockdep_stats_show+0xa20/0xa20 [ 2023.699940][ T6807] ? seq_file_path+0x30/0x30 [ 2023.704721][ T6807] ? mutex_lock_io_nested+0xf70/0xf70 [ 2023.710118][ T6807] ? lock_acquire+0x58a/0x740 [ 2023.715156][ T6807] ? kasan_unpoison+0x3c/0x60 [ 2023.719843][ T6807] lc_show+0x10a/0x210 [ 2023.723924][ T6807] seq_read_iter+0xb66/0x1220 [ 2023.728617][ T6807] proc_reg_read_iter+0x1fb/0x2d0 [ 2023.733651][ T6807] new_sync_read+0x41e/0x6e0 [ 2023.738272][ T6807] ? ksys_lseek+0x1b0/0x1b0 [ 2023.742784][ T6807] ? lock_acquire+0x58a/0x740 [ 2023.747563][ T6807] vfs_read+0x35c/0x570 [ 2023.751737][ T6807] ksys_read+0x12d/0x250 [ 2023.756003][ T6807] ? vfs_write+0xa30/0xa30 [ 2023.760429][ T6807] ? syscall_enter_from_user_mode+0x27/0x70 [ 2023.766335][ T6807] do_syscall_64+0x3a/0xb0 [ 2023.770764][ T6807] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2023.776685][ T6807] RIP: 0033:0x7f99856e2910 [ 2023.781104][ T6807] Code: b6 fe ff ff 48 8d 3d 0f be 08 00 48 83 ec 08 e8 06 db 01 00 66 0f 1f 44 00 00 83 3d f9 2d 2c 00 00 75 10 b8 00 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 de 9b 01 00 48 89 04 24 [ 2023.800719][ T6807] RSP: 002b:00007ffee7328628 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 2023.809169][ T6807] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f99856e2910 [ 2023.817150][ T6807] RDX: 0000000000020000 RSI: 0000564290b2a000 RDI: 0000000000000003 [ 2023.825123][ T6807] RBP: 0000564290b2a000 R08: 0000000000000003 R09: 0000000000021010 [ 2023.833107][ T6807] R10: 0000000000000002 R11: 0000000000000246 R12: 0000564290b2a000 [ 2023.841091][ T6807] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000001000 [ 2023.849074][ T6807] [ 2023.851408][ T6807] The buggy address belongs to the variable: [ 2023.857388][ T6807] lock_classes_in_use+0x410/0x420 [ 2023.862510][ T6807] [ 2023.864826][ T6807] Memory state around the buggy address: [ 2023.870450][ T6807] ffffffff90225b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 2023.878511][ T6807] ffffffff90225c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 2023.886572][ T6807] >ffffffff90225c80: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00 [ 2023.894628][ T6807] ^ [ 2023.900256][ T6807] ffffffff90225d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 2023.908317][ T6807] ffffffff90225d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 2023.916377][ T6807] ================================================================== > turning off the locking correctness validator. > CPU: 0 PID: 5917 Comm: syz-executor.4 Not tainted 5.12.0-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:79 [inline] > dump_stack+0x141/0x1d7 lib/dump_stack.c:120 > register_lock_class.cold+0x14/0x19 kernel/locking/lockdep.c:1281 > __lock_acquire+0x102/0x5230 kernel/locking/lockdep.c:4781 > lock_acquire kernel/locking/lockdep.c:5512 [inline] > lock_acquire+0x1ab/0x740 kernel/locking/lockdep.c:5477 > flush_workqueue+0x110/0x13e0 kernel/workqueue.c:2786 > drain_workqueue+0x1a5/0x3c0 kernel/workqueue.c:2951 > destroy_workqueue+0x71/0x800 kernel/workqueue.c:4382 > alloc_workqueue+0xc40/0xef0 kernel/workqueue.c:4343 > wg_newlink+0x43d/0x9e0 drivers/net/wireguard/device.c:335 > __rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3452 > rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3500 > rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5562 > netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 > netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] > netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 > netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 > sock_sendmsg_nosec net/socket.c:654 [inline] > sock_sendmsg+0xcf/0x120 net/socket.c:674 > ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 > ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 > __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 > do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x4665d9 > Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007fb25febe188 EFLAGS: 00000246 ORIG_RAX: 000000000000002e > RAX: ffffffffffffffda RBX: 000000000056c0b0 RCX: 00000000004665d9 > RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000005 > RBP: 00000000004bfcb9 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c0b0 > R13: 00007fff30a5021f R14: 00007fb25febe300 R15: 0000000000022000 > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkaller at googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe at googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/0000000000003687bd05c2b2401d%40google.com. From dvyukov at google.com Wed May 19 20:09:35 2021 From: dvyukov at google.com (Dmitry Vyukov) Date: Wed, 19 May 2021 22:09:35 +0200 Subject: [syzbot] BUG: MAX_LOCKDEP_KEYS too low! (2) In-Reply-To: References: <0000000000003687bd05c2b2401d@google.com> Message-ID: On Wed, May 19, 2021 at 9:58 PM Randy Dunlap wrote: > > On 5/19/21 12:48 PM, Dmitry Vyukov wrote: > > On Wed, May 19, 2021 at 7:35 PM syzbot > > wrote: > >> > >> Hello, > >> > >> syzbot found the following issue on: > >> > >> HEAD commit: b81ac784 net: cdc_eem: fix URL to CDC EEM 1.0 spec > >> git tree: net > >> console output: https://syzkaller.appspot.com/x/log.txt?x=15a257c3d00000 > >> kernel config: https://syzkaller.appspot.com/x/.config?x=5b86a12e0d1933b5 > >> dashboard link: https://syzkaller.appspot.com/bug?extid=a70a6358abd2c3f9550f > >> > >> Unfortunately, I don't have any reproducer for this issue yet. > >> > >> IMPORTANT: if you fix the issue, please add the following tag to the commit: > >> Reported-by: syzbot+a70a6358abd2c3f9550f at syzkaller.appspotmail.com > >> > >> BUG: MAX_LOCKDEP_KEYS too low! > > > > include/linux/lockdep.h > > #define MAX_LOCKDEP_KEYS_BITS 13 > #define MAX_LOCKDEP_KEYS (1UL << MAX_LOCKDEP_KEYS_BITS) Ouch, so it's not configurable yet :( Unless, of course, we identify the offender that produced thousands of lock classes in the log and fix it. > Documentation/locking/lockdep-design.rst: > > Troubleshooting: > ---------------- > > The validator tracks a maximum of MAX_LOCKDEP_KEYS number of lock classes. > Exceeding this number will trigger the following lockdep warning:: > > (DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS)) > > By default, MAX_LOCKDEP_KEYS is currently set to 8191, and typical > desktop systems have less than 1,000 lock classes, so this warning > normally results from lock-class leakage or failure to properly > initialize locks. These two problems are illustrated below: > > > > > What config controls this? I don't see "MAX_LOCKDEP_KEYS too low" in > > any of the config descriptions... > > Here is what syzbot used: > > > > CONFIG_LOCKDEP=y > > CONFIG_LOCKDEP_BITS=16 > > CONFIG_LOCKDEP_CHAINS_BITS=17 > > CONFIG_LOCKDEP_STACK_TRACE_BITS=20 > > CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14 > > CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12 > > > > We already bumped most of these. > > The log contains dump of the lockdep debug files, is there any offender? > > > > Also looking at the log I noticed a memory safety bug in lockdep implementation: > > ... > > -- > ~Randy > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe at googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/c545268c-fe62-883c-4c46-974b3bb3cea1%40infradead.org. From rdunlap at infradead.org Wed May 19 19:57:58 2021 From: rdunlap at infradead.org (Randy Dunlap) Date: Wed, 19 May 2021 12:57:58 -0700 Subject: [syzbot] BUG: MAX_LOCKDEP_KEYS too low! (2) In-Reply-To: References: <0000000000003687bd05c2b2401d@google.com> Message-ID: On 5/19/21 12:48 PM, Dmitry Vyukov wrote: > On Wed, May 19, 2021 at 7:35 PM syzbot > wrote: >> >> Hello, >> >> syzbot found the following issue on: >> >> HEAD commit: b81ac784 net: cdc_eem: fix URL to CDC EEM 1.0 spec >> git tree: net >> console output: https://syzkaller.appspot.com/x/log.txt?x=15a257c3d00000 >> kernel config: https://syzkaller.appspot.com/x/.config?x=5b86a12e0d1933b5 >> dashboard link: https://syzkaller.appspot.com/bug?extid=a70a6358abd2c3f9550f >> >> Unfortunately, I don't have any reproducer for this issue yet. >> >> IMPORTANT: if you fix the issue, please add the following tag to the commit: >> Reported-by: syzbot+a70a6358abd2c3f9550f at syzkaller.appspotmail.com >> >> BUG: MAX_LOCKDEP_KEYS too low! > include/linux/lockdep.h #define MAX_LOCKDEP_KEYS_BITS 13 #define MAX_LOCKDEP_KEYS (1UL << MAX_LOCKDEP_KEYS_BITS) Documentation/locking/lockdep-design.rst: Troubleshooting: ---------------- The validator tracks a maximum of MAX_LOCKDEP_KEYS number of lock classes. Exceeding this number will trigger the following lockdep warning:: (DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS)) By default, MAX_LOCKDEP_KEYS is currently set to 8191, and typical desktop systems have less than 1,000 lock classes, so this warning normally results from lock-class leakage or failure to properly initialize locks. These two problems are illustrated below: > > What config controls this? I don't see "MAX_LOCKDEP_KEYS too low" in > any of the config descriptions... > Here is what syzbot used: > > CONFIG_LOCKDEP=y > CONFIG_LOCKDEP_BITS=16 > CONFIG_LOCKDEP_CHAINS_BITS=17 > CONFIG_LOCKDEP_STACK_TRACE_BITS=20 > CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14 > CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12 > > We already bumped most of these. > The log contains dump of the lockdep debug files, is there any offender? > > Also looking at the log I noticed a memory safety bug in lockdep implementation: ... -- ~Randy From rm at romanrm.net Thu May 20 06:15:30 2021 From: rm at romanrm.net (Roman Mamedov) Date: Thu, 20 May 2021 11:15:30 +0500 Subject: lost connection on dynamic IP In-Reply-To: References: <20210519234310.66ea294e@natsu> Message-ID: <20210520111530.4568a14f@natsu> On Thu, 20 May 2021 00:28:08 +0200 Vicente Bergas wrote: > There is a public IP assigned to the router. The IP is dynamic, so, it > can change from time to time, but, once assigned, it is exclusive to > the router. > There is no carrier-grade NAT. > I've configured the router to forward the wireguard port to the > server, so, it is like the server is directly connected to the > Internet. > I think the PersistentKeepalive on the server side is not required. Is it? I believe it is. Consider the server public IP has changed. The server sends no Keepalives. The client sends them to the server's old IP. The whole thing broke. > So, what do you mean is that wireguard does a single DNS resolution at > the beginning and further DNS resolutions need to be done elsewere. Is > that correct? Yes. -- With respect, Roman From vicencb at gmail.com Wed May 19 22:28:08 2021 From: vicencb at gmail.com (Vicente Bergas) Date: Thu, 20 May 2021 00:28:08 +0200 Subject: lost connection on dynamic IP In-Reply-To: <20210519234310.66ea294e@natsu> References: <20210519234310.66ea294e@natsu> Message-ID: Hello Roman, On Wed, May 19, 2021 at 8:43 PM Roman Mamedov wrote: > > On Tue, 18 May 2021 13:22:31 +0200 > Vicente Bergas wrote: > > > A server connected to the Internet through an ISP that provides a > > dynamic IP with NAT. > > If it's NAT, then your server has no dedicated public IP? What do you update > to DNS, IP of the ISP's NAT pool (shared IP with many other customers)? There is a public IP assigned to the router. The IP is dynamic, so, it can change from time to time, but, once assigned, it is exclusive to the router. There is no carrier-grade NAT. I've configured the router to forward the wireguard port to the server, so, it is like the server is directly connected to the Internet. I think the PersistentKeepalive on the server side is not required. Is it? On the client side, instead, the router has no port forwarded and also, i think, there is CGNAT. That is the reason PersistentKeepalive is present. > > I think the issue happens when the ISP on the server side shuts down > > the Internet connection for more than 1 hour! Then, it is restored > > with a new IP. > > inadyn detects the new IP and updates the DNS. > > At this point the Internet connection is operational again, but the > > client remains disconnected until rebooted. > > > > Is this scenario expected to work due to the "Built-in Roaming" ? > > It might work, helped by PersistentKeepalive, and as long as the server and the > client don't change their IPs/ports *at the same time*. To protect against > that, or to improve resiliency in general (and assuming there's actually no NAT > at the server side after all), your client should resolve the DNS record for > the server periodically, and in case the IP changed, call "wg set [interface] > peer [key] endpoint [IP:port]". So, what do you mean is that wireguard does a single DNS resolution at the beginning and further DNS resolutions need to be done elsewere. Is that correct? > With respect, > Roman Regards, Vicen?. From penguin-kernel at i-love.sakura.ne.jp Thu May 20 05:02:00 2021 From: penguin-kernel at i-love.sakura.ne.jp (Tetsuo Handa) Date: Thu, 20 May 2021 14:02:00 +0900 Subject: [syzbot] BUG: MAX_LOCKDEP_KEYS too low! (2) In-Reply-To: References: <0000000000003687bd05c2b2401d@google.com> Message-ID: <208cd812-214f-ef2f-26ec-cc7a73953885@i-love.sakura.ne.jp> On 2021/05/20 5:09, Dmitry Vyukov wrote: > On Wed, May 19, 2021 at 9:58 PM Randy Dunlap wrote: >> >> On 5/19/21 12:48 PM, Dmitry Vyukov wrote: >>> On Wed, May 19, 2021 at 7:35 PM syzbot >>> wrote: >>>> >>>> Hello, >>>> >>>> syzbot found the following issue on: >>>> >>>> HEAD commit: b81ac784 net: cdc_eem: fix URL to CDC EEM 1.0 spec >>>> git tree: net >>>> console output: https://syzkaller.appspot.com/x/log.txt?x=15a257c3d00000 >>>> kernel config: https://syzkaller.appspot.com/x/.config?x=5b86a12e0d1933b5 >>>> dashboard link: https://syzkaller.appspot.com/bug?extid=a70a6358abd2c3f9550f >>>> >>>> Unfortunately, I don't have any reproducer for this issue yet. >>>> >>>> IMPORTANT: if you fix the issue, please add the following tag to the commit: >>>> Reported-by: syzbot+a70a6358abd2c3f9550f at syzkaller.appspotmail.com >>>> >>>> BUG: MAX_LOCKDEP_KEYS too low! >>> >> >> include/linux/lockdep.h >> >> #define MAX_LOCKDEP_KEYS_BITS 13 >> #define MAX_LOCKDEP_KEYS (1UL << MAX_LOCKDEP_KEYS_BITS) > > Ouch, so it's not configurable yet :( I didn't try to make this value configurable, for > Unless, of course, we identify the offender that produced thousands of > lock classes in the log and fix it. number of currently active locks should decrease over time. If this message is printed, increasing this value unlikely helps. We have https://lkml.kernel.org/r/c099ad52-0c2c-b886-bae2-c64bd8626452 at ozlabs.ru which seems to be unresolved. Regarding this report, cleanup of bonding device is too slow to catch up to creation of bonding device? We might need to throttle creation of BPF, bonding etc. which involve WQ operation for clean up ? From rm at romanrm.net Thu May 20 16:20:56 2021 From: rm at romanrm.net (Roman Mamedov) Date: Thu, 20 May 2021 21:20:56 +0500 Subject: lost connection on dynamic IP In-Reply-To: <20210520111530.4568a14f@natsu> References: <20210519234310.66ea294e@natsu> <20210520111530.4568a14f@natsu> Message-ID: <20210520212056.1ddd3d5a@natsu> On Thu, 20 May 2021 11:15:30 +0500 Roman Mamedov wrote: > > So, what do you mean is that wireguard does a single DNS resolution at > > the beginning and further DNS resolutions need to be done elsewere. Is > > that correct? > > Yes. I also remembered a case where just PersistentKeepalive won't save you, and periodic DNS resolution on clients becomes mandatory. It is when the server's physical location gets a power cut. On new boot-up (and router power-on) it gets a new IP from the ISP, and has no idea where all the clients are. The communication is broken until clients recheck the DNS record and update the server's endpoint from that. WG does not do this on its own. -- With respect, Roman From max.schulze at online.de Thu May 20 19:23:50 2021 From: max.schulze at online.de (Max Schulze) Date: Thu, 20 May 2021 21:23:50 +0200 Subject: lost connection on dynamic IP In-Reply-To: <20210520212056.1ddd3d5a@natsu> References: <20210519234310.66ea294e@natsu> <20210520111530.4568a14f@natsu> <20210520212056.1ddd3d5a@natsu> Message-ID: On 20.05.21 18:20, Roman Mamedov wrote: > On Thu, 20 May 2021 11:15:30 +0500 > Roman Mamedov wrote: > >>> So, what do you mean is that wireguard does a single DNS resolution at >>> the beginning and further DNS resolutions need to be done elsewere. Is >>> that correct? >> Yes. > I also remembered a case where just PersistentKeepalive won't save you, and > periodic DNS resolution on clients becomes mandatory. It is when the server's > physical location gets a power cut. On new boot-up (and router power-on) it > gets a new IP from the ISP, and has no idea where all the clients are. The > communication is broken until clients recheck the DNS record and update the > server's endpoint from that. WG does not do this on its own. > Just to point out what 'others are doing' - openwrt has a watchdog script [1] that might be run with cron every 15 mins */15 * * * * /usr/bin/wireguard_watchdog which will update the new endpoint if the last handshake is too old: wg set ${iface} peer ${public_key} endpoint "${endpoint_host}:${endpoint_port}" It needs PersistenKeepalive also, if i understand correctly. [1] https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/utils/wireguard-tools/files/wireguard_watchdog;hb=HEAD -- Max From dvyukov at google.com Fri May 21 07:04:39 2021 From: dvyukov at google.com (Dmitry Vyukov) Date: Fri, 21 May 2021 09:04:39 +0200 Subject: [syzbot] BUG: MAX_LOCKDEP_KEYS too low! (2) In-Reply-To: <208cd812-214f-ef2f-26ec-cc7a73953885@i-love.sakura.ne.jp> References: <0000000000003687bd05c2b2401d@google.com> <208cd812-214f-ef2f-26ec-cc7a73953885@i-love.sakura.ne.jp> Message-ID: On Thu, May 20, 2021 at 7:02 AM Tetsuo Handa wrote: > > On 2021/05/20 5:09, Dmitry Vyukov wrote: > > On Wed, May 19, 2021 at 9:58 PM Randy Dunlap wrote: > >> > >> On 5/19/21 12:48 PM, Dmitry Vyukov wrote: > >>> On Wed, May 19, 2021 at 7:35 PM syzbot > >>> wrote: > >>>> > >>>> Hello, > >>>> > >>>> syzbot found the following issue on: > >>>> > >>>> HEAD commit: b81ac784 net: cdc_eem: fix URL to CDC EEM 1.0 spec > >>>> git tree: net > >>>> console output: https://syzkaller.appspot.com/x/log.txt?x=15a257c3d00000 > >>>> kernel config: https://syzkaller.appspot.com/x/.config?x=5b86a12e0d1933b5 > >>>> dashboard link: https://syzkaller.appspot.com/bug?extid=a70a6358abd2c3f9550f > >>>> > >>>> Unfortunately, I don't have any reproducer for this issue yet. > >>>> > >>>> IMPORTANT: if you fix the issue, please add the following tag to the commit: > >>>> Reported-by: syzbot+a70a6358abd2c3f9550f at syzkaller.appspotmail.com > >>>> > >>>> BUG: MAX_LOCKDEP_KEYS too low! > >>> > >> > >> include/linux/lockdep.h > >> > >> #define MAX_LOCKDEP_KEYS_BITS 13 > >> #define MAX_LOCKDEP_KEYS (1UL << MAX_LOCKDEP_KEYS_BITS) > > > > Ouch, so it's not configurable yet :( > > I didn't try to make this value configurable, for > > > Unless, of course, we identify the offender that produced thousands of > > lock classes in the log and fix it. > > number of currently active locks should decrease over time. > If this message is printed, increasing this value unlikely helps. > > We have https://lkml.kernel.org/r/c099ad52-0c2c-b886-bae2-c64bd8626452 at ozlabs.ru > which seems to be unresolved. > > Regarding this report, cleanup of bonding device is too slow to catch up to > creation of bonding device? > > We might need to throttle creation of BPF, bonding etc. which involve WQ operation for clean up? I see, thanks for digging into it. Unbounded asynchronous queueing is always a recipe for disaster... I assume such issues can affect production as well, if some program creates namespaces/devices in a loop. So I think ideally such things are throttled/restricted in the kernel, e.g. new namespaces/devices are not created if some threshold is reached. Potentially syzkaller could throttle creation of new namespaces/devices if we find a good and reliable way to monitor backlog. Something like the length of a particular workqueue. It may also help with OOMs. But so far I haven't found it. From hankbao84 at gmail.com Sat May 22 18:41:18 2021 From: hankbao84 at gmail.com (Hank Bao) Date: Sun, 23 May 2021 02:41:18 +0800 Subject: Error when connecting from windows client Message-ID: Hello Everyone. I believe I've encountered the same issue. My Wintun interface failed to boot up, and I found a warning sign on the Wintun adapter in the device manager. After digging into the setupapi.dev.log, I found that it's the same error message as Johnathan's. ! dvi: Device pending start: Device has problem: 0x38 (CM_PROB_NEED_CLASS_CONFIG), problem status: 0x00000000. I noticed that the Cisco AnyConnect secure mobility client got a virtual adapter installed in the system, which instance id is also 'ROOT\NET\0000'. Hopefully, this will be helpful. Regards, Hank Bao From vicencb at gmail.com Sun May 23 11:44:59 2021 From: vicencb at gmail.com (Vicente Bergas) Date: Sun, 23 May 2021 13:44:59 +0200 Subject: lost connection on dynamic IP In-Reply-To: References: <20210519234310.66ea294e@natsu> <20210520111530.4568a14f@natsu> <20210520212056.1ddd3d5a@natsu> Message-ID: On Thu, May 20, 2021 at 9:23 PM Max Schulze wrote: > On 20.05.21 18:20, Roman Mamedov wrote: > > On Thu, 20 May 2021 11:15:30 +0500 > > Roman Mamedov wrote: > > > >>> So, what do you mean is that wireguard does a single DNS resolution at > >>> the beginning and further DNS resolutions need to be done elsewere. Is > >>> that correct? > >> Yes. > Just to point out what 'others are doing' - openwrt has a watchdog > script [1] that might be run with cron every 15 mins > > */15 * * * * /usr/bin/wireguard_watchdog > > which will update the new endpoint if the last handshake is too old: > > wg set ${iface} peer ${public_key} endpoint > "${endpoint_host}:${endpoint_port}" > > It needs PersistenKeepalive also, if i understand correctly. > > [1] > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/utils/wireguard-tools/files/wireguard_watchdog;hb=HEAD > > -- > > Max Hello, i've been running this script on a setup with a wg interface with a single peer: while true ; do sleep 300 curr=$(date +%s) prev=$(wg show wg0 latest-handshakes | cut -f2) elapsed=$(( ${curr} - ${prev} )) [ ${elapsed} -ge 300 ] && wg syncconf wg0 /etc/wireguard/wg0.conf done on the client side for 3 days and the issue occurred once again. This time the connection was restablished automatically and no manual intervention was required. Thank you Max and Roman. Regards, Vicen?. From emile at emilenijssen.nl Mon May 24 09:35:29 2021 From: emile at emilenijssen.nl (Emile Nijssen) Date: Mon, 24 May 2021 11:35:29 +0200 Subject: [wg-easy] The easiest way to run WireGuard VPN + Web-based Admin UI. Message-ID: <428B744A-4C1C-482F-9990-E790EB1622B7@emilenijssen.nl> Hi all, I want to share my open source project, wg-easy. It's an easy to setup, pre-built docker image that runs WireGuard with a beautiful Web UI for clients management on top of it. You can view/create/disable/delete clients, show a QR code, or download their .conf. There's even Gravatar support :) It's intended for new users (your typical Raspberry Pi hobbyist) to get started easily. Check it out: https://github.com/WeeJeWel/wg-easy (there's a screenshot of the Web UI in the repository). --- Emile Nijssen From nautsch2 at gmail.com Tue May 25 10:34:35 2021 From: nautsch2 at gmail.com (Andre Naujoks) Date: Tue, 25 May 2021 12:34:35 +0200 Subject: wireguard windows socket binds to device Message-ID: Hi all. I am currently trying to create a wireguard tunnel over another VPN under windows. The setup would be a wirguard tunnel through an openvpn connection. However the wireguard implementation on windows forcibly binds itself to the network device with the default route (which is fortunately visible in the wireguard log). The wireguard peer however resides inside the other VPN and is thus not reached by the windows client. Is there a reason why the routing of the host machine is forcibly bypassed by binding to a specific network device or is this simply a bug in the windows implementation? Best regards and thanks in advance Andre From kurtis.mullins at gmail.com Tue May 25 16:57:31 2021 From: kurtis.mullins at gmail.com (Kurtis Mullins) Date: Tue, 25 May 2021 12:57:31 -0400 Subject: Icon height on MacOS Message-ID: <800DE710-9096-488D-915D-FD1604CEDEAE@gmail.com> Hello, I am not sure where to make feature requests. The icon on MacOS fills up the full height of the menu bar and looks out-of-place compared to the other icons. It would be nice to shrink the height down a bit. I?m happy to share a screenshot if that would help; could use a suggestion on an image sharing service first. Thanks, -Kurtis From lists.zx2c4.com.486782 at postermail.com Wed May 26 10:47:44 2021 From: lists.zx2c4.com.486782 at postermail.com (lists.zx2c4.com.486782 at postermail.com) Date: Wed, 26 May 2021 10:47:44 +0000 Subject: wireguard-android: tunnel not working after reboot Message-ID: Hello, When setting up a WireGuard tunnel as Always-on VPN and verifying it works, it stops working after a reboot. In order to make it work again, it must be disconnected and reconnected manually in either Android settings or WireGuard app. I am not sure whether this is a WireGuard or Android/LineageOS bug, but Always-on VPN works fine with OpenVPN. Environment: Device: Nexus 5X OS: LineageOS 15.1 (Android 8.1.0) WireGuard app version: 1.0.20210506 Steps to reproduce: 1. Setup a new tunnel in WireGuard app and enable it 2. Verify the tunnel works 3. Set WireGuard as Always-on VPN in Android settings (i.e. Settings > Network > Internet > VPN) 4. Reboot device Expected behavior: VPN tunnel should work normally. Actual behavior: VPN tunnel doesn't work. Log extract: 05-26 11:56:50.068 6186 6327 D WireGuard/GoBackend/pluto: peer(i8Gy?i2D8) - Sending handshake initiation 05-26 11:56:50.069 6186 6327 E WireGuard/GoBackend/pluto: peer(i8Gy?i2D8) - Failed to send handshake initiation: no known endpoint for peer 05-26 11:56:55.168 6186 6327 D WireGuard/GoBackend/pluto: peer(i8Gy?i2D8) - Handshake did not complete after 5 seconds, retrying (try 10) Attached are WireGuard app's log and configuration. Thank you. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wireguard-log.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wireguard-export.conf URL: From Jason at zx2c4.com Wed May 26 14:33:15 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 26 May 2021 16:33:15 +0200 Subject: wireguard-android: tunnel not working after reboot In-Reply-To: References: Message-ID: Does your endpoint contain a DNS hostname rather than an IP, perchance? From Jason at zx2c4.com Wed May 26 14:37:25 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 26 May 2021 16:37:25 +0200 Subject: wireguard windows socket binds to device In-Reply-To: References: Message-ID: This might help: https://lists.zx2c4.com/pipermail/wireguard/2021-March/006442.html From Jason at zx2c4.com Wed May 26 15:06:50 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 26 May 2021 17:06:50 +0200 Subject: wireguard-android: tunnel not working after reboot In-Reply-To: References: Message-ID: On Wed, May 26, 2021 at 4:57 PM wrote: > > Yes, it does. Unfortunately, the endpoint has a dynamic IP address, so I am stuck with that. > > Is there anything I can do about it? Probably not, but it does explain the error well, which means I can likely fix the bug. Thanks for the report. Jason From Jason at zx2c4.com Wed May 26 16:06:38 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 26 May 2021 18:06:38 +0200 Subject: wireguard-android: tunnel not working after reboot In-Reply-To: References: Message-ID: Kind of terrible (for the reasons mentioned within), but: https://git.zx2c4.com/wireguard-android/commit/?id=d139fd0c5cabe2db496e78477fdf57142ce97a36 From nautsch2 at gmail.com Thu May 27 09:22:23 2021 From: nautsch2 at gmail.com (Andre Naujoks) Date: Thu, 27 May 2021 11:22:23 +0200 Subject: wireguard windows socket binds to device In-Reply-To: References: Message-ID: Am 26.05.21 um 16:37 schrieb Jason A. Donenfeld: > This might help: > https://lists.zx2c4.com/pipermail/wireguard/2021-March/006442.html > Hi. Thanks for the answer. The registry keys were not present, so I added them manually. That and the PostUp script seem to have done the trick. For now, I see this as a viable workaround. Thank you for that. I still see this as a bug though. I read the reasoning behind it in the other mail (https://lore.kernel.org/wireguard/CAHmME9rXV2_YG3fGMErDeTjfHeNKhDC2cCYA6Kw93n9A328QpQ at mail.gmail.com/). Maybe only use the IP_UNICAST_IF to the default route if AllowedIPs is 0.0.0.0/0 and/or ::/0? For all other cases it seems unnecessary (errors in those cases would be configuration problems on the users side) and in some cases (i.e. mine, the non-default-route case) just wrong. Thanks again and best Regards Andre From raoul.bhatia at radarcs.com Sun May 30 13:20:21 2021 From: raoul.bhatia at radarcs.com (Raoul Bhatia) Date: Sun, 30 May 2021 13:20:21 +0000 Subject: Wireguard connection lost between peers In-Reply-To: <1CCB5519-611B-4377-97A9-0F9179E3C6F2@radarcs.com> References: <1CCB5519-611B-4377-97A9-0F9179E3C6F2@radarcs.com> Message-ID: <31839237-F1FE-4760-82B1-7C01E93753E1@radarcs.com> (Appologies for top posting; my current email client is not mailing list friendly) Hi Jason and community, We are continuing to observe the mentioned behavior and it seems that the error we are seeing is mostly triggered during high(er) load situations i.e. 500Mbit-2000Mbit and as we move around 200GB+ chunks of data via TCP over WireGuard. Until now, we managed to keep things more stable but then again faced an outage. Observations: A. Connectivity is more likely to break between the same components, i.e. I saw the same container fail 1-2x per day within a week of monitoring [1]; I see the issue more often between the _same_ physical hosts of the cluster (however, these are the more traffic heavy ones) B. I've also seen an interesting behavior where I had to reset a connection 2x between 2 physical servers within a short amount of time and first from node2 and then from node1. Please find the related config snippets and journalctl -k messages (filtered for the peers) here: * https://nem3d.net/node1.txt * https://nem3d.net/node2.txt Approx timeline of events: 1. 05/26 One container failed on node2 and was recovered from the host [1] 2. 05/26 Almost exactly 1,5h later, the connection between node2 and node1 broke with "stopped hearing back after 15 seconds" 3. 05/27 06.02h on node2 I manually used peer remove node1/syncconf to re-establish the connection 4. 05/27 06.25h on node1 logged "stopped hearing back after 15 seconds" 5. 05/27 06.31h on node1 I used peer remove node2/syncconf to re-establish the connection Afterwards, things worked smooth again. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Environment: Debian 9 with kernel from package and wireguard from buster-backports $ uname -r -v -m -o 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64 GNU/Linux $ modinfo wireguard filename: /lib/modules/4.9.0-11-amd64/updates/dkms/wireguard.ko intree: Y alias: net-pf-16-proto-16-family-wireguard alias: rtnl-link-wireguard version: 1.0.20210124 author: Jason A. Donenfeld description: WireGuard secure network tunnel license: GPL v2 srcversion: 507BE23A7368F016AEBAF94 depends: udp_tunnel,ip6_udp_tunnel retpoline: Y vermagic: 4.9.0-11-amd64 SMP mod_unload modversions Thanks, Raoul [1] I created a small cronjob that checks host/container connectivty via icmp/ping and initiates the wg dump/peer remove/syncconf recovery procedure in case of an error. On 12.05.21, 07:19, "Raoul Bhatia" wrote: > [...] >> That's surprising behavior. Thanks for debugging it. Can you see if >> you can reproduce with dynamic logging enabled? That'll give some >> useful information in dmesg: >> >> # modprobe wireguard && echo module wireguard +p > >> /sys/kernel/debug/dynamic_debug/control > > I did enable the debug control and also set > sysctl -w net.core.message_cost=0 > and have extracted a sample of the issue. > Please find it here https://nem3d.net/wireguard_20210512a.txt > > From my observation, it is always the following symptoms: > 1. Everything is WORKING: > LXC container d1-h sends handshake initiation. > Host wg0 receives, re-creates keypair, answers > d1-h receives, re-creates keypair, sends keepalive > wg0 receives keepalive > etc. > > > 2. Somewhen it BREAKS > d1-h stopps hearing back after 15 seconds. > Initialization loop like mentioned above > d1-h stopps hearing back after 15 seconds. > etc. > > As mentioned, the resolution is to dump the config, > remove the peer, and syncconf to restore. > This time, I used "nsenter -n" to apply this procedure to the > unprivileged container interface d1-h. > > Lastly, we also saw similar behavior even between 2 physical hosts. > I will try to gather similar debug information. > > Please let me know if further information is needed to > better understand the problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6069 bytes Desc: not available URL: From Jason at zx2c4.com Mon May 31 07:49:40 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 31 May 2021 09:49:40 +0200 Subject: IRC channels #wireguard, #cgit, and #pass open on Libera.Chat Message-ID: Hi, The IRC channels #wireguard, #cgit, and #pass will now be on Libera.Chat in official capacity. This means that you can now connect with other users and developers of these projects by pointing your IRC client at: Server: irc.libera.chat Port: 6697 with TLS (aka "ssl" or "secure port") Channel: #wireguard, #cgit, and #pass On Weechat: /server add libera irc.libera.chat/6697 -ssl -autoconnect -autojoin=#wireguard,#cgit,#pass /save /connect libera On irssi: /network add libera /channel add -auto #wireguard libera /channel add -auto #cgit libera /channel add -auto #pass libera /server add -network libera -auto -tls irc.libera.chat 6697 /save /connect libera Users who want to simply pop online ephemerally to ask a quick question can also use the web interface: . Though do note that the community generally appreciates it when people maintain a more continuous presence logged in ("idling"). For folks who want to connect to IRC longer term, but don't want to futz around with overly technical things, services like IRCCloud.com (paid) and Matrix.org (free) offer a way of staying connected to IRC networks from your web browser and mobile phone. With large swaths of the free software community recently departing our old home of freenode, the choice was between the new Libera.Chat IRC network, the venerable OFTC IRC network, and something newfangled like Slack, Discord, Mattermost, Rocket.Chat, Zulip, or `ncat -l -k --chat`. This choice was not easy. The primary advantage of the newer platforms is their broader accessibility to less technical users and expanded feature sets. Their disadvantage is that they are standalone/siloed tools, which don't promote cross-pollination between our community and other communities. In contrast, the primary advantage of IRC in general over the more recent communication tools is the community around IRC. Somebody hanging out over in #archlinux asking a question about WireGuard is easily referred to #wireguard for additional troubleshooting, and vice versa. And different types of users and developers frequently meet and share ideas. It is a commons of sorts. There are additional differences between the platforms (with keywords like "javascript" or "licensing" or "curmudgeonly"), but this distinction between being part of the larger community and free software ecosystem, and not, strikes me as a critical basis of decision. In deciding between Libera.Chat and OFTC, the decision was a bit harder, but ultimately was made with the same principle in mind. OFTC is old and stable, having apparently few governance issues over a long history. In contrast, Libera.Chat is brand new and was created by a group of volunteers that, while having an impressive history of running freenode successfully for many years, have just emerged from a highly publicized conflict. However, Libera.Chat hosts a significantly larger portion of the free software community than OFTC. Seeing that our motivation for remaining on IRC in the first place is community, going with the larger network makes most sense, even if it does not yet have a proven track record of stability. I hope that rationale makes sense. See you all in the new channels. Thanks, Jason PS: WireGuard community members, enthusiasts, contributors, and developers can now request a "wireguard/tunneler/{nick}" cloak from Mira (mira), Aaron (amdj), or me (zx2c4). Shoot one of us a message on IRC and we'll set it up.