From tech at tootai.net  Thu Dec  1 12:24:07 2022
From: tech at tootai.net (Daniel)
Date: Thu, 1 Dec 2022 13:24:07 +0100
Subject: Wireguard on Asahi Debian
Message-ID: <0ac435a3-95f4-c005-9834-ffb44360536c@tootai.net>

Hi All,

I installed Asahi/Debian Bookworm from

https://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian/

and face a problem: installing wireguard shipped the Debian arm kernel 
and I can't get wg to work.

Is there a solution for this ?
-- 
Daniel

From tech at tootai.net  Thu Dec  1 13:06:53 2022
From: tech at tootai.net (Daniel)
Date: Thu, 1 Dec 2022 14:06:53 +0100
Subject: Wireguard on Asahi Debian
In-Reply-To: <0ac435a3-95f4-c005-9834-ffb44360536c@tootai.net>
References: <0ac435a3-95f4-c005-9834-ffb44360536c@tootai.net>
Message-ID: <8941df6b-2935-ef5c-a4b3-15a715258ef2@tootai.net>

OK, wg is in the kernel, sorry to have bother you.

Le 01/12/2022 ? 13:24, Daniel a ?crit?:
> Hi All,
> 
> I installed Asahi/Debian Bookworm from
> 
> https://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian/
> 
> and face a problem: installing wireguard shipped the Debian arm kernel 
> and I can't get wg to work.
> 
> Is there a solution for this ?

-- 
Daniel Huhardeaux
+33.368460088 at tootai.net	      sip:820 at sip.tootai.net
+41.445532125 at swiss-itech.ch		    tootaiNET

From Jason at zx2c4.com  Thu Dec  1 13:08:13 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 1 Dec 2022 14:08:13 +0100
Subject: Wireguard on Asahi Debian
In-Reply-To: <0ac435a3-95f4-c005-9834-ffb44360536c@tootai.net>
References: <0ac435a3-95f4-c005-9834-ffb44360536c@tootai.net>
Message-ID: <Y4inPePWAWCQ/Ejp@zx2c4.com>

On Thu, Dec 01, 2022 at 01:24:07PM +0100, Daniel wrote:
> Hi All,
> 
> I installed Asahi/Debian Bookworm from
> 
> https://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian/
> 
> and face a problem: installing wireguard shipped the Debian arm kernel 
> and I can't get wg to work.
> 
> Is there a solution for this ?

Appears to be available in Asahi's kernel:
https://github.com/AsahiLinux/PKGBUILDs/blob/9fb6fddfdd388190c099a723f046acf7b8b6bd39/linux-asahi/config#L2462

From droidbittin at gmail.com  Thu Dec  1 14:26:29 2022
From: droidbittin at gmail.com (Luna Jernberg)
Date: Thu, 1 Dec 2022 15:26:29 +0100
Subject: Wireguard on Asahi Debian
In-Reply-To: <Y4inPePWAWCQ/Ejp@zx2c4.com>
References: <0ac435a3-95f4-c005-9834-ffb44360536c@tootai.net>
 <Y4inPePWAWCQ/Ejp@zx2c4.com>
Message-ID: <CADo9pHij0DqLsHswwquhesi3N1L8v1n7-eaCjNQ=rV1vgO_Y-A@mail.gmail.com>

Thats Asahi with Arch Linux however and not Debian

On Thu, Dec 1, 2022 at 2:10 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> On Thu, Dec 01, 2022 at 01:24:07PM +0100, Daniel wrote:
> > Hi All,
> >
> > I installed Asahi/Debian Bookworm from
> >
> > https://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian/
> >
> > and face a problem: installing wireguard shipped the Debian arm kernel
> > and I can't get wg to work.
> >
> > Is there a solution for this ?
>
> Appears to be available in Asahi's kernel:
> https://github.com/AsahiLinux/PKGBUILDs/blob/9fb6fddfdd388190c099a723f046acf7b8b6bd39/linux-asahi/config#L2462

From droidbittin at gmail.com  Thu Dec  1 14:51:06 2022
From: droidbittin at gmail.com (Luna Jernberg)
Date: Thu, 1 Dec 2022 15:51:06 +0100
Subject: Wireguard on Asahi Debian
In-Reply-To: <104a34b9-f27e-0daa-4ef2-d5e71af65639@tootai.net>
References: <0ac435a3-95f4-c005-9834-ffb44360536c@tootai.net>
 <Y4inPePWAWCQ/Ejp@zx2c4.com>
 <CADo9pHij0DqLsHswwquhesi3N1L8v1n7-eaCjNQ=rV1vgO_Y-A@mail.gmail.com>
 <104a34b9-f27e-0daa-4ef2-d5e71af65639@tootai.net>
Message-ID: <CADo9pHi_42SWhMBTzWDfxeWO+pVr5kniXOBELOjwyzUdk2jLwg@mail.gmail.com>

Ah i see

On Thu, Dec 1, 2022 at 3:49 PM Daniel <tech at tootai.net> wrote:
>
>
> Le 01/12/2022 ? 15:26, Luna Jernberg a ?crit :
> > Thats Asahi with Arch Linux however and not Debian
> https://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian/
> >
> > On Thu, Dec 1, 2022 at 2:10 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> >> On Thu, Dec 01, 2022 at 01:24:07PM +0100, Daniel wrote:
> >>> Hi All,
> >>>
> >>> I installed Asahi/Debian Bookworm from
> >>>
> >>> https://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian/
> >>>
> >>> and face a problem: installing wireguard shipped the Debian arm kernel
> >>> and I can't get wg to work.
> >>>
> >>> Is there a solution for this ?
> >> Appears to be available in Asahi's kernel:
> >> https://github.com/AsahiLinux/PKGBUILDs/blob/9fb6fddfdd388190c099a723f046acf7b8b6bd39/linux-asahi/config#L2462
>
> --
> Daniel Huhardeaux
> +33.368460088 at tootai.net              sip:820 at sip.tootai.net
> +41.445532125 at swiss-itech.ch                tootaiNET

From houmie at gmail.com  Mon Dec  5 17:15:09 2022
From: houmie at gmail.com (Houman)
Date: Mon, 5 Dec 2022 17:15:09 +0000
Subject: Wireguard iOS crashes after upgrading to XCode 14
In-Reply-To: <CAHmME9pZy+EYQbmrBi_5Ei191zJ_X3imSuZ_U766HhXp39MHbA@mail.gmail.com>
References: <CABBZOsks3ZnpcURYHSQcaWCe8ETY21zitPY5TvtTaAm38DT5EA@mail.gmail.com>
 <834CB179-958C-4C0E-8B17-9918C8A992FB@mullvad.net>
 <CABBZOs=9VVSDEGPw1eQWmusJotA5toLCn1-uNQeZ+moPthAOxg@mail.gmail.com>
 <CAHmME9pZy+EYQbmrBi_5Ei191zJ_X3imSuZ_U766HhXp39MHbA@mail.gmail.com>
Message-ID: <CABBZOs=yZj7R1oWrj9EUDk8QSGfbhNSjBLmhOtqAPrT5Esrh7A@mail.gmail.com>

Hi Jason,

I was wondering if there are still any plans to focus on the Apple
development and bring the repo more up-to-date, please.

Since the latest major development on the Wireguard Linux repo seems
to have finished by 31st October, I was wondering if Apple dev could
be prioritised next, please.

I can see there was an update to the License file a couple of weeks
ago. But the last real commit on Apple repo is from Sep 2021.

Many Thanks,
Houman


On Thu, 22 Sept 2022 at 10:38, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> On 9/22/22, Houman <houmie at gmail.com> wrote:
> > Hi Andrej,
> >
> > It works, well done!
> >
> > A strange thing though, before your patch I was still able to connect
> > to the VPN server, if I changed the schema to Release instead of
> > Debug.  Now with your patch it also works under Debug schema, which is
> > fantastic.
> > What could be the technical reason that it still worked under Release?
> >
> > And what will happen now, are you able to actually get this patch
> > released on the official repo? The repo hasn't been updated for a
> > year.  :-)
> >
>
> Yeah, I'll circle back Apple development at some point. No worries.
>
> Jason

From Jason at zx2c4.com  Mon Dec  5 17:40:55 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 5 Dec 2022 18:40:55 +0100
Subject: Wireguard iOS crashes after upgrading to XCode 14
In-Reply-To: <CABBZOs=yZj7R1oWrj9EUDk8QSGfbhNSjBLmhOtqAPrT5Esrh7A@mail.gmail.com>
References: <CABBZOsks3ZnpcURYHSQcaWCe8ETY21zitPY5TvtTaAm38DT5EA@mail.gmail.com>
 <834CB179-958C-4C0E-8B17-9918C8A992FB@mullvad.net>
 <CABBZOs=9VVSDEGPw1eQWmusJotA5toLCn1-uNQeZ+moPthAOxg@mail.gmail.com>
 <CAHmME9pZy+EYQbmrBi_5Ei191zJ_X3imSuZ_U766HhXp39MHbA@mail.gmail.com>
 <CABBZOs=yZj7R1oWrj9EUDk8QSGfbhNSjBLmhOtqAPrT5Esrh7A@mail.gmail.com>
Message-ID: <CAHmME9ptx38ZFKs3Ve2=d3G787S4oNzoyJqefAbFwEcdWYbT_w@mail.gmail.com>

On Mon, Dec 5, 2022 at 6:15 PM Houman <houmie at gmail.com> wrote:
>
> Hi Jason,
>
> I was wondering if there are still any plans to focus on the Apple
> development and bring the repo more up-to-date, please.
>
> Since the latest major development on the Wireguard Linux repo seems
> to have finished by 31st October, I was wondering if Apple dev could
> be prioritised next, please.
>
> I can see there was an update to the License file a couple of weeks
> ago. But the last real commit on Apple repo is from Sep 2021.

Yes that's the next priority.

From dxld at darkboxed.org  Wed Dec  7 18:00:31 2022
From: dxld at darkboxed.org (=?UTF-8?q?Daniel=20Gr=C3=B6ber?=)
Date: Wed,  7 Dec 2022 19:00:31 +0100
Subject: [PATCH] wg-quick: Allow setting iface VRF in PreUp hook
Message-ID: <20221207180031.301766-1-dxld@darkboxed.org>

Currently PreUp hooks run before the wireguard device is created. This is
problematic for moving the device into a Linux VRFs as this will currently
clear all assigned IPv6 addressess (possibly a bug), so if we did this in
PostUp (i.e. before add_addr) we'll have to manually re-add all assigned
addresses. This is obviously less than ideal.

Instead create the wg device just before running PreUp hooks. We apply this
to all platforms for consistency.

Test case:

    $ ip link add vrf-test type vrf table 1234
    $ ip link add wg-test type wireguard
    $ ip addr add dev wg-test 192.168.42.42/24
    $ ip addr add dev wg-test fe80::/64

    $ ip -br addr show wg-test
    wg-test          DOWN           192.168.42.42/24 fe80::/64

    $ ip link set dev wg-test master vrf-test

    $ ip -br addr show wg-test
    wg-test          DOWN           192.168.42.42/32

Signed-off-by: Daniel Gr?ber <dxld at darkboxed.org>
---
 src/wg-quick/darwin.bash  | 2 +-
 src/wg-quick/freebsd.bash | 2 +-
 src/wg-quick/linux.bash   | 2 +-
 src/wg-quick/openbsd.bash | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/wg-quick/darwin.bash b/src/wg-quick/darwin.bash
index 8e46818..c938112 100755
--- a/src/wg-quick/darwin.bash
+++ b/src/wg-quick/darwin.bash
@@ -452,8 +452,8 @@ cmd_up() {
 	local i
 	get_real_interface && die "\`$INTERFACE' already exists as \`$REAL_INTERFACE'"
 	trap 'del_if; del_routes; exit' INT TERM EXIT
-	execute_hooks "${PRE_UP[@]}"
 	add_if
+	execute_hooks "${PRE_UP[@]}"
 	set_config
 	for i in "${ADDRESSES[@]}"; do
 		add_addr "$i"
diff --git a/src/wg-quick/freebsd.bash b/src/wg-quick/freebsd.bash
index b529ab2..f72daf6 100755
--- a/src/wg-quick/freebsd.bash
+++ b/src/wg-quick/freebsd.bash
@@ -420,8 +420,8 @@ cmd_up() {
 	local i
 	[[ -z $(ifconfig "$INTERFACE" 2>/dev/null) ]] || die "\`$INTERFACE' already exists"
 	trap 'del_if; del_routes; clean_temp; exit' INT TERM EXIT
-	execute_hooks "${PRE_UP[@]}"
 	add_if
+	execute_hooks "${PRE_UP[@]}"
 	set_config
 	for i in "${ADDRESSES[@]}"; do
 		add_addr "$i"
diff --git a/src/wg-quick/linux.bash b/src/wg-quick/linux.bash
index 69e5bef..4193ce5 100755
--- a/src/wg-quick/linux.bash
+++ b/src/wg-quick/linux.bash
@@ -327,8 +327,8 @@ cmd_up() {
 	local i
 	[[ -z $(ip link show dev "$INTERFACE" 2>/dev/null) ]] || die "\`$INTERFACE' already exists"
 	trap 'del_if; exit' INT TERM EXIT
-	execute_hooks "${PRE_UP[@]}"
 	add_if
+	execute_hooks "${PRE_UP[@]}"
 	set_config
 	for i in "${ADDRESSES[@]}"; do
 		add_addr "$i"
diff --git a/src/wg-quick/openbsd.bash b/src/wg-quick/openbsd.bash
index 2adfe46..b58ecf5 100755
--- a/src/wg-quick/openbsd.bash
+++ b/src/wg-quick/openbsd.bash
@@ -417,8 +417,8 @@ cmd_up() {
 	local i
 	get_real_interface && die "\`$INTERFACE' already exists as \`$REAL_INTERFACE'"
 	trap 'del_if; del_routes; exit' INT TERM EXIT
-	execute_hooks "${PRE_UP[@]}"
 	add_if
+	execute_hooks "${PRE_UP[@]}"
 	set_config
 	for i in "${ADDRESSES[@]}"; do
 		add_addr "$i"
-- 
2.30.2


From houmie at gmail.com  Fri Dec  9 19:39:27 2022
From: houmie at gmail.com (Houman)
Date: Fri, 9 Dec 2022 19:39:27 +0000
Subject: Can Wireguard-tools be installed with Checkinstall?
Message-ID: <CABBZOs=pDoCAOdwBxRtzU5Bs__QA-pbc1mYqUddLT379BKw0kg@mail.gmail.com>

I would like to have an option to uninstall Wireguard, compile the
latest and reinstall again.
But I can't see "make uninstall" to be implemented. So what are my
options to get a clean reinstallation of Wireguard?

I was playing with Checkinstall to install it as a package instead.

git clone https://git.zx2c4.com/wireguard-tools
make -C wireguard-tools/src -j$(nproc)
cd ~/wireguard-tools/src/
sudo checkinstall -y

But even though the package is created and installed, it doesn't
behave the same way as if I installed it with "make install".
For example there is no /etc/wireguard, even though it said it created it:

========================= Installation results ===========================
'wg' -> '/usr/bin/wg'
'man/wg.8' -> '/usr/share/man/man8/wg.8'
'completion/wg.bash-completion' -> '/usr/share/bash-completion/completions/wg'
'wg-quick/linux.bash' -> '/usr/bin/wg-quick'
install: creating directory '/etc/wireguard'
'man/wg-quick.8' -> '/usr/share/man/man8/wg-quick.8'
'completion/wg-quick.bash-completion' ->
'/usr/share/bash-completion/completions/wg-quick'
'systemd/wg-quick.target' -> '/lib/systemd/system/wg-quick.target'
'systemd/wg-quick at .service' -> '/lib/systemd/system/wg-quick at .service'

======================== Installation successful ==========================

Is Wireguard not compatible with Checkinstall?  Have I missed
anything? Is there a better way to uninstall the compiled version of
Wireguard cleanly without using checkinstall?

Many Thanks,
Houman

From jirislaby at kernel.org  Mon Dec 12 11:47:12 2022
From: jirislaby at kernel.org (Jiri Slaby (SUSE))
Date: Mon, 12 Dec 2022 12:47:12 +0100
Subject: [PATCH v2] wireguard (gcc13): move ULLs limits away from enum
Message-ID: <20221212114712.11802-1-jirislaby@kernel.org>

Since gcc13, each member of an enum has the same type as the enum [1]. And
that is inherited from its members. Provided these two:
  REKEY_AFTER_MESSAGES = 1ULL << 60
  REJECT_AFTER_MESSAGES = U64_MAX - COUNTER_WINDOW_SIZE - 1
the named type is unsigned long.

This generates warnings with gcc-13:
  error: format '%d' expects argument of type 'int', but argument 6 has type 'long unsigned int'

Define such high values as macros instead of in the enum. Note that
enums are not guaranteed to hold unsigned longs in any way.

And use BIT_ULL() for REKEY_AFTER_MESSAGES.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113

Cc: Martin Liska <mliska at suse.cz>
Cc: "Jason A. Donenfeld" <Jason at zx2c4.com>
Cc: "David S. Miller" <davem at davemloft.net>
Cc: Eric Dumazet <edumazet at google.com>
Cc: Jakub Kicinski <kuba at kernel.org>
Cc: Paolo Abeni <pabeni at redhat.com>
Cc: wireguard at lists.zx2c4.com
Cc: netdev at vger.kernel.org
Signed-off-by: Jiri Slaby (SUSE) <jirislaby at kernel.org>
---

Notes:
    [v2] move the constant out of enum (David)

 drivers/net/wireguard/messages.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireguard/messages.h b/drivers/net/wireguard/messages.h
index 208da72673fc..048125bdcd23 100644
--- a/drivers/net/wireguard/messages.h
+++ b/drivers/net/wireguard/messages.h
@@ -37,9 +37,10 @@ enum counter_values {
 	COUNTER_WINDOW_SIZE = COUNTER_BITS_TOTAL - COUNTER_REDUNDANT_BITS
 };
 
+#define REKEY_AFTER_MESSAGES	BIT_ULL(60)
+#define REJECT_AFTER_MESSAGES	(U64_MAX - COUNTER_WINDOW_SIZE - 1)
+
 enum limits {
-	REKEY_AFTER_MESSAGES = 1ULL << 60,
-	REJECT_AFTER_MESSAGES = U64_MAX - COUNTER_WINDOW_SIZE - 1,
 	REKEY_TIMEOUT = 5,
 	REKEY_TIMEOUT_JITTER_MAX_JIFFIES = HZ / 3,
 	REKEY_AFTER_TIME = 120,
-- 
2.38.1


From Jason at zx2c4.com  Mon Dec 12 14:23:34 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 12 Dec 2022 15:23:34 +0100
Subject: [PATCH v2] wireguard (gcc13): move ULLs limits away from enum
In-Reply-To: <20221212114712.11802-1-jirislaby@kernel.org>
References: <20221212114712.11802-1-jirislaby@kernel.org>
Message-ID: <Y5c5ZtXy2nQzBmGC@zx2c4.com>

I have this queued up already as:
https://git.zx2c4.com/wireguard-linux/commit/?id=3d9d8bba03db21f3276324cdba43c82be5d60729

I liked this variant better.

Jason

From pmenzel at molgen.mpg.de  Thu Dec  8 08:27:57 2022
From: pmenzel at molgen.mpg.de (Paul Menzel)
Date: Thu, 8 Dec 2022 09:27:57 +0100
Subject: [PATCH] wg-quick: Allow setting iface VRF in PreUp hook
In-Reply-To: <20221207180031.301766-1-dxld@darkboxed.org>
References: <20221207180031.301766-1-dxld@darkboxed.org>
Message-ID: <5bdb73b3-8f1f-2641-206b-a9ca2df7d71f@molgen.mpg.de>

Dear Daniel,


Thank you for your patch.


Am 07.12.22 um 19:00 schrieb Daniel Gr?ber:

[?]

> Test case:
> 
>      $ ip link add vrf-test type vrf table 1234
>      $ ip link add wg-test type wireguard
>      $ ip addr add dev wg-test 192.168.42.42/24
>      $ ip addr add dev wg-test fe80::/64
> 
>      $ ip -br addr show wg-test
>      wg-test          DOWN           192.168.42.42/24 fe80::/64
> 
>      $ ip link set dev wg-test master vrf-test
> 
>      $ ip -br addr show wg-test
>      wg-test          DOWN           192.168.42.42/32

Should this be /24?

[?]


Kind regards,

Paul

From mar.kolya at gmail.com  Fri Dec 16 02:12:09 2022
From: mar.kolya at gmail.com (Nikolay Martynov)
Date: Thu, 15 Dec 2022 21:12:09 -0500
Subject: Connection hangs over CGNAT (Starlink)
Message-ID: <CALGY4fuH9oXpa34nzyj+jc94sS+ZQ5MaJUktFJF2A2-p213vEQ@mail.gmail.com>

Hi!

I'm experiencing strange behaviour with wireguard: from time to time
connection 'freezes'.
Most often I'm observing this on an Android phone when connected from
my home over Starlink.
Server: latest Openwrt, Client: latest Android app.
The connection establishes and works fine for some time. After some
time the client still shows connection is established, but no incoming
data is coming.
On a server side 'latest handshake' goes into hours/days.
The freeze happens randomly, for no apparent reason and I think only
over starlink. I do not think I have ever observed this problem on
cell networks.

Reconnection solves the problem immediately.
I did some tcpdumping when the problem was present and found the following:
* Server side sees incoming traffic from the client and sends responses.
* On my own router connected to Starlink (i.e. interface between my
router and Starlink router) I see data going from the client to the
server - but no packets coming back.

So my 'hypothesis' is that somehow Starlink's CGNAT 'forgets' one side
of the connection - and so data continues to go in one direction, but
it doesn't come back. The thing with the wireguard is that it looks
like it doesn't change the outgoing port when it attempts to do
another handshake. This means that it continues using the same 'half
broken' connection forever.

I think the same happens to me at least once on a Linux client - but
the difference with the phone is that the phone is always on and
therefore the duration of the connection is much longer.

I tried experimenting with keepalive messages - but it looks like they
make no difference. Once connection freezes I see keepalived arriving
onto the server, server sending reply - but that reply never arrives
to the client.

It looks like the solution to this problem would be for the client to
use a different outgoing port when sending a handshake but I was not
able to find an option for that.

Is this something that is possible to do?
Thanks!


-- 
Martynov Nikolay.
Email: mar.kolya at gmail.com

From szymonn841 at gmail.com  Sat Dec 17 22:15:49 2022
From: szymonn841 at gmail.com (Szymon Nowak)
Date: Sat, 17 Dec 2022 23:15:49 +0100
Subject: Connection hangs over CGNAT (Starlink)
In-Reply-To: <CALGY4fuH9oXpa34nzyj+jc94sS+ZQ5MaJUktFJF2A2-p213vEQ@mail.gmail.com>
References: <CALGY4fuH9oXpa34nzyj+jc94sS+ZQ5MaJUktFJF2A2-p213vEQ@mail.gmail.com>
Message-ID: <CA+hy6dtEXTG9wQJ0Cb=2iEgZd6bOpCghBinawgS5UPCQ+95sGA@mail.gmail.com>

I've noticed the same thing on a WIndows client, it happens when you
provide internet from two sources, e.g. Wifi and mobile network or
Wifi and LAN in case of computer, When one of these sources has a
problem and internet is not available on it. Then Wireguard stops
working even though it doesn't break the tunnel. Completely
disconnecting the faulty connection and reconnecting the tunleu solves
this problem. I don't know why they don't work even though the tunnel
is connected

On Sat, Dec 17, 2022 at 11:05 PM Nikolay Martynov <mar.kolya at gmail.com> wrote:
>
> Hi!
>
> I'm experiencing strange behaviour with wireguard: from time to time
> connection 'freezes'.
> Most often I'm observing this on an Android phone when connected from
> my home over Starlink.
> Server: latest Openwrt, Client: latest Android app.
> The connection establishes and works fine for some time. After some
> time the client still shows connection is established, but no incoming
> data is coming.
> On a server side 'latest handshake' goes into hours/days.
> The freeze happens randomly, for no apparent reason and I think only
> over starlink. I do not think I have ever observed this problem on
> cell networks.
>
> Reconnection solves the problem immediately.
> I did some tcpdumping when the problem was present and found the following:
> * Server side sees incoming traffic from the client and sends responses.
> * On my own router connected to Starlink (i.e. interface between my
> router and Starlink router) I see data going from the client to the
> server - but no packets coming back.
>
> So my 'hypothesis' is that somehow Starlink's CGNAT 'forgets' one side
> of the connection - and so data continues to go in one direction, but
> it doesn't come back. The thing with the wireguard is that it looks
> like it doesn't change the outgoing port when it attempts to do
> another handshake. This means that it continues using the same 'half
> broken' connection forever.
>
> I think the same happens to me at least once on a Linux client - but
> the difference with the phone is that the phone is always on and
> therefore the duration of the connection is much longer.
>
> I tried experimenting with keepalive messages - but it looks like they
> make no difference. Once connection freezes I see keepalived arriving
> onto the server, server sending reply - but that reply never arrives
> to the client.
>
> It looks like the solution to this problem would be for the client to
> use a different outgoing port when sending a handshake but I was not
> able to find an option for that.
>
> Is this something that is possible to do?
> Thanks!
>
>
> --
> Martynov Nikolay.
> Email: mar.kolya at gmail.com

From lists at lonnie.abelbeck.com  Sun Dec 18 13:24:04 2022
From: lists at lonnie.abelbeck.com (Lonnie Abelbeck)
Date: Sun, 18 Dec 2022 07:24:04 -0600
Subject: Connection hangs over CGNAT (Starlink)
In-Reply-To: <CALGY4fuH9oXpa34nzyj+jc94sS+ZQ5MaJUktFJF2A2-p213vEQ@mail.gmail.com>
References: <CALGY4fuH9oXpa34nzyj+jc94sS+ZQ5MaJUktFJF2A2-p213vEQ@mail.gmail.com>
Message-ID: <4EFD21AB-EB67-4561-B5C6-28E3BC582936@lonnie.abelbeck.com>

Have you tried reducing the MTU of the WG tunnel?

I have a similar use case with a WG tunnel over a T-Mobile Home Internet (TMHI) CGNAT network.

After some testing determining the reduced MTU of the TMHI network, I set the WG endpoints' MTU to be 1340.

The WG tunnel has been rock solid.

Lonnie


> On Dec 15, 2022, at 8:12 PM, Nikolay Martynov <mar.kolya at gmail.com> wrote:
> 
> Hi!
> 
> I'm experiencing strange behaviour with wireguard: from time to time
> connection 'freezes'.
> Most often I'm observing this on an Android phone when connected from
> my home over Starlink.
> Server: latest Openwrt, Client: latest Android app.
> The connection establishes and works fine for some time. After some
> time the client still shows connection is established, but no incoming
> data is coming.
> On a server side 'latest handshake' goes into hours/days.
> The freeze happens randomly, for no apparent reason and I think only
> over starlink. I do not think I have ever observed this problem on
> cell networks.
> 
> Reconnection solves the problem immediately.
> I did some tcpdumping when the problem was present and found the following:
> * Server side sees incoming traffic from the client and sends responses.
> * On my own router connected to Starlink (i.e. interface between my
> router and Starlink router) I see data going from the client to the
> server - but no packets coming back.
> 
> So my 'hypothesis' is that somehow Starlink's CGNAT 'forgets' one side
> of the connection - and so data continues to go in one direction, but
> it doesn't come back. The thing with the wireguard is that it looks
> like it doesn't change the outgoing port when it attempts to do
> another handshake. This means that it continues using the same 'half
> broken' connection forever.
> 
> I think the same happens to me at least once on a Linux client - but
> the difference with the phone is that the phone is always on and
> therefore the duration of the connection is much longer.
> 
> I tried experimenting with keepalive messages - but it looks like they
> make no difference. Once connection freezes I see keepalived arriving
> onto the server, server sending reply - but that reply never arrives
> to the client.
> 
> It looks like the solution to this problem would be for the client to
> use a different outgoing port when sending a handshake but I was not
> able to find an option for that.
> 
> Is this something that is possible to do?
> Thanks!
> 
> 
> -- 
> Martynov Nikolay.
> Email: mar.kolya at gmail.com
> 


From mar.kolya at gmail.com  Sat Dec 31 01:08:25 2022
From: mar.kolya at gmail.com (Nikolay Martynov)
Date: Fri, 30 Dec 2022 20:08:25 -0500
Subject: Connection hangs over CGNAT (Starlink)
In-Reply-To: <2c5180c0a406fb9a68f367213940d06b2d4340ec.camel@withtel.com.au>
References: <CALGY4fuH9oXpa34nzyj+jc94sS+ZQ5MaJUktFJF2A2-p213vEQ@mail.gmail.com>
 <2c5180c0a406fb9a68f367213940d06b2d4340ec.camel@withtel.com.au>
Message-ID: <CALGY4ftUHpgANxbCo=i9GdTB1Tvodd-j0zzu897HPA3__JXw-g@mail.gmail.com>

Hi!

FWIW, reducing MTU doesn't seem to help. Also it looks like I almost
never experience this on a cell network and experience this sometimes
multiple times in an hour on startlink.
At any rate the problem can easily be simulated by just using
iptables. If for whatever reason packets are cut on the return path
for an established connection a new connection (with new source port)
is not reestablished resulting in connection effectively hanging
forever. I do not want to sound too presumptuous, but this seems like
a clear bug to me.

On Sun, Dec 18, 2022 at 10:41 PM Dean Davis <dean_davis at withtel.com.au> wrote:
>
> hi
>
>
> same issue
>
>
> I do kind of a automated ping test and if fails on the server side to
> many times bring down interface and then back up in a bash script
>
> with
>
> nmcli connection down wg0 && nmcli connection up wg0
>
>
> to me it looks to be connection state issue difference between new and
> established/related  ( can not confirm )
>
>
> ugly but works for me
>
>
>
> regards
> dean
>
>
> On Thu, 2022-12-15 at 21:12 -0500, Nikolay Martynov wrote:
> > Hi!
> >
> > I'm experiencing strange behaviour with wireguard: from time to time
> > connection 'freezes'.
> > Most often I'm observing this on an Android phone when connected from
> > my home over Starlink.
> > Server: latest Openwrt, Client: latest Android app.
> > The connection establishes and works fine for some time. After some
> > time the client still shows connection is established, but no
> > incoming
> > data is coming.
> > On a server side 'latest handshake' goes into hours/days.
> > The freeze happens randomly, for no apparent reason and I think only
> > over starlink. I do not think I have ever observed this problem on
> > cell networks.
> >
> > Reconnection solves the problem immediately.
> > I did some tcpdumping when the problem was present and found the
> > following:
> > * Server side sees incoming traffic from the client and sends
> > responses.
> > * On my own router connected to Starlink (i.e. interface between my
> > router and Starlink router) I see data going from the client to the
> > server - but no packets coming back.
> >
> > So my 'hypothesis' is that somehow Starlink's CGNAT 'forgets' one
> > side
> > of the connection - and so data continues to go in one direction, but
> > it doesn't come back. The thing with the wireguard is that it looks
> > like it doesn't change the outgoing port when it attempts to do
> > another handshake. This means that it continues using the same 'half
> > broken' connection forever.
> >
> > I think the same happens to me at least once on a Linux client - but
> > the difference with the phone is that the phone is always on and
> > therefore the duration of the connection is much longer.
> >
> > I tried experimenting with keepalive messages - but it looks like
> > they
> > make no difference. Once connection freezes I see keepalived arriving
> > onto the server, server sending reply - but that reply never arrives
> > to the client.
> >
> > It looks like the solution to this problem would be for the client to
> > use a different outgoing port when sending a handshake but I was not
> > able to find an option for that.
> >
> > Is this something that is possible to do?
> > Thanks!
> >
> >
>


-- 
Martynov Nikolay.
Email: mar.kolya at gmail.com

From dean_davis at withtel.com.au  Mon Dec 19 03:41:34 2022
From: dean_davis at withtel.com.au (Dean Davis)
Date: Mon, 19 Dec 2022 13:41:34 +1000
Subject: Connection hangs over CGNAT (Starlink)
In-Reply-To: <CALGY4fuH9oXpa34nzyj+jc94sS+ZQ5MaJUktFJF2A2-p213vEQ@mail.gmail.com>
References: <CALGY4fuH9oXpa34nzyj+jc94sS+ZQ5MaJUktFJF2A2-p213vEQ@mail.gmail.com>
Message-ID: <2c5180c0a406fb9a68f367213940d06b2d4340ec.camel@withtel.com.au>

hi


same issue


I do kind of a automated ping test and if fails on the server side to
many times bring down interface and then back up in a bash script

with 

nmcli connection down wg0 && nmcli connection up wg0


to me it looks to be connection state issue difference between new and
established/related  ( can not confirm )


ugly but works for me 



regards
dean


On Thu, 2022-12-15 at 21:12 -0500, Nikolay Martynov wrote:
> Hi!
> 
> I'm experiencing strange behaviour with wireguard: from time to time
> connection 'freezes'.
> Most often I'm observing this on an Android phone when connected from
> my home over Starlink.
> Server: latest Openwrt, Client: latest Android app.
> The connection establishes and works fine for some time. After some
> time the client still shows connection is established, but no
> incoming
> data is coming.
> On a server side 'latest handshake' goes into hours/days.
> The freeze happens randomly, for no apparent reason and I think only
> over starlink. I do not think I have ever observed this problem on
> cell networks.
> 
> Reconnection solves the problem immediately.
> I did some tcpdumping when the problem was present and found the
> following:
> * Server side sees incoming traffic from the client and sends
> responses.
> * On my own router connected to Starlink (i.e. interface between my
> router and Starlink router) I see data going from the client to the
> server - but no packets coming back.
> 
> So my 'hypothesis' is that somehow Starlink's CGNAT 'forgets' one
> side
> of the connection - and so data continues to go in one direction, but
> it doesn't come back. The thing with the wireguard is that it looks
> like it doesn't change the outgoing port when it attempts to do
> another handshake. This means that it continues using the same 'half
> broken' connection forever.
> 
> I think the same happens to me at least once on a Linux client - but
> the difference with the phone is that the phone is always on and
> therefore the duration of the connection is much longer.
> 
> I tried experimenting with keepalive messages - but it looks like
> they
> make no difference. Once connection freezes I see keepalived arriving
> onto the server, server sending reply - but that reply never arrives
> to the client.
> 
> It looks like the solution to this problem would be for the client to
> use a different outgoing port when sending a handshake but I was not
> able to find an option for that.
> 
> Is this something that is possible to do?
> Thanks!
> 
> 


From hr567 at hr567.me  Thu Dec 29 13:59:42 2022
From: hr567 at hr567.me (hr567 at hr567.me)
Date: Thu, 29 Dec 2022 13:59:42 +0000
Subject: example.c in wintun project does not work as expected
Message-ID: <000801d91b8d$cb88f730$629ae590$@hr567.me>

I'm learning how to use wintun with its example.c file, however, the example
program doesn't run correctly currently. I found that the cause of the error
was calling WintunGetAdapterLUID before WintunStartSession. In this case,
WintunGetAdapterLUID set the InterfaceLuid to 0. I'm not sure if the problem
is caused by the wintun version or the OS version. I am using wintul.dll
version 0.14.1 and Windows 11 x86_64.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - hr567 at hr567.me - c8b7d072.asc
Type: application/pgp-keys
Size: 1757 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20221229/8bdf1f49/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 509 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20221229/8bdf1f49/attachment.sig>

From pierrick.rouxel at me.com  Fri Dec 30 08:16:23 2022
From: pierrick.rouxel at me.com (Pierrick Rouxel)
Date: Fri, 30 Dec 2022 09:16:23 +0100
Subject: Rounded-rectangle icons for MacOS
Message-ID: <8DCA5CA8-6560-45ED-8D07-99FAD6568E61@me.com>

Hello team !

I?m a mac user on macOS Ventura. I use the wireguard client.

Since macOS Big Sur, Apple changed the guidelines of app icon. It should be defined in a rounded rectangle : https://developer.apple.com/design/human-interface-guidelines/foundations/app-icons/#platform-considerations

This change affect :
    ? The app icon
    ? The VPN setting icons
    ? Maybe others ?

I would have been happy to submit a PR but I saw that the github projet is a mirror of your private repository. 
So, I ask to you here, can you change app  icons to follow Apple Guidelines and provide a better intergration in the last versions of macOS ?

Regards,
Pierrick.