From peljasz at yahoo.co.uk  Thu Jun  8 09:30:26 2023
From: peljasz at yahoo.co.uk (lejeczek)
Date: Thu, 8 Jun 2023 11:30:26 +0200
Subject: IP which is not there but wg0 replies - ?
References: <980aa33e-4bb4-e746-b45a-c0ab0ea7e371.ref@yahoo.co.uk>
Message-ID: <980aa33e-4bb4-e746-b45a-c0ab0ea7e371@yahoo.co.uk>


Hi guys.

Purely accidentally I stumbled uppon:

-> $ ping 10.1.101
PING 10.1.101 (10.1.0.101) 56(84) bytes of data.
64 bytes from 10.1.0.101: icmp_seq=1 ttl=64 time=0.148 ms
64 bytes from 10.1.0.101: icmp_seq=2 ttl=64 time=0.415 ms

-> $ ip a ls dev wg0
17: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8920 qdisc 
noqueue state UNKNOWN group default qlen 1000
 ??? link/none
 ??? inet 10.1.0.99/24 scope global wg0
 ?????? valid_lft forever preferred_lft forever
peer:
14: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8920 qdisc 
noqueue state UNKNOWN group default qlen 1000
 ??? link/none
 ??? inet 10.1.0.100/24 scope global wg0
 ?????? valid_lft forever preferred_lft forever

This a wg0's IP.
Someone could shed a bit more light on that - I'd imagine 
many will appreciate, I will.
I'm thinking - is my ipcalcing messed up..
many thanks, L.


From peljasz at yahoo.co.uk  Thu Jun  8 11:45:27 2023
From: peljasz at yahoo.co.uk (lejeczek)
Date: Thu, 8 Jun 2023 13:45:27 +0200
Subject: How to post to the mailling list? (Was: IP which is not there but
 wg0 replies - ?)
In-Reply-To: <20230608114742.63648767@parrot>
References: <980aa33e-4bb4-e746-b45a-c0ab0ea7e371.ref@yahoo.co.uk>
 <980aa33e-4bb4-e746-b45a-c0ab0ea7e371@yahoo.co.uk>
 <20230608114742.63648767@parrot>
Message-ID: <8792819b-a595-7789-fc6f-3bce89d13d28@yahoo.co.uk>



On 08/06/2023 11:47, Marek K?the wrote:
> Hello,
>
> I would be interested to know how you managed to post something on the
> Mailling list? I have been trying to do this for several weeks, however
> my messages do not arrive. Do you have a special trick?
>
> I would appreciate an answer!
>
> Greetings
> Marek K?the
>
> On Thu, 8 Jun 2023 11:30:26 +0200
> lejeczek <peljasz at yahoo.co.uk> wrote:
>
>> Hi guys.
>>
>> Purely accidentally I stumbled uppon:
>>
>> -> $ ping 10.1.101
>> PING 10.1.101 (10.1.0.101) 56(84) bytes of data.
>> 64 bytes from 10.1.0.101: icmp_seq=1 ttl=64 time=0.148 ms
>> 64 bytes from 10.1.0.101: icmp_seq=2 ttl=64 time=0.415 ms
>>
>> -> $ ip a ls dev wg0
>> 17: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8920 qdisc
>> noqueue state UNKNOWN group default qlen 1000
>>   ??? link/none
>>   ??? inet 10.1.0.99/24 scope global wg0
>>   ?????? valid_lft forever preferred_lft forever
>> peer:
>> 14: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8920 qdisc
>> noqueue state UNKNOWN group default qlen 1000
>>   ??? link/none
>>   ??? inet 10.1.0.100/24 scope global wg0
>>   ?????? valid_lft forever preferred_lft forever
>>
>> This a wg0's IP.
>> Someone could shed a bit more light on that - I'd imagine
>> many will appreciate, I will.
>> I'm thinking - is my ipcalcing messed up..
>> many thanks, L.
>>
>
Apparently the list (maintainers?) practice old & healthy 
habit - which placing replies below/at bottom also is -? to 
accept only "text" format for a message. (I presume for new 
message/thread)
Test that if you will. (Thunderbird works)
regards, L.

From peljasz at yahoo.co.uk  Thu Jun  8 12:10:55 2023
From: peljasz at yahoo.co.uk (lejeczek)
Date: Thu, 8 Jun 2023 14:10:55 +0200
Subject: How to post to the mailling list? (Was: IP which is not there but
 wg0 replies - ?)
In-Reply-To: <20230608140422.24071746@parrot>
References: <980aa33e-4bb4-e746-b45a-c0ab0ea7e371.ref@yahoo.co.uk>
 <980aa33e-4bb4-e746-b45a-c0ab0ea7e371@yahoo.co.uk>
 <20230608114742.63648767@parrot>
 <8792819b-a595-7789-fc6f-3bce89d13d28@yahoo.co.uk>
 <20230608140422.24071746@parrot>
Message-ID: <bb78b2f2-0076-134c-6ab7-03ab282c39b3@yahoo.co.uk>



On 08/06/2023 14:04, Marek K?the wrote:
> On Thu, 8 Jun 2023 13:45:27 +0200
> lejeczek <peljasz at yahoo.co.uk> wrote:
>
>> On 08/06/2023 11:47, Marek K?the wrote:
>>> Hello,
>>>
>>> I would be interested to know how you managed to post something on the
>>> Mailling list? I have been trying to do this for several weeks, however
>>> my messages do not arrive. Do you have a special trick?
>>>
>>> I would appreciate an answer!
>>>
>>> Greetings
>>> Marek K?the
>>>
>>> On Thu, 8 Jun 2023 11:30:26 +0200
>>> lejeczek <peljasz at yahoo.co.uk> wrote:
>>>   
>>>> Hi guys.
>>>>
>>>> Purely accidentally I stumbled uppon:
>>>>   
>>>> -> $ ping 10.1.101
>>>> PING 10.1.101 (10.1.0.101) 56(84) bytes of data.
>>>> 64 bytes from 10.1.0.101: icmp_seq=1 ttl=64 time=0.148 ms
>>>> 64 bytes from 10.1.0.101: icmp_seq=2 ttl=64 time=0.415 ms
>>>>   
>>>> -> $ ip a ls dev wg0
>>>> 17: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8920 qdisc
>>>> noqueue state UNKNOWN group default qlen 1000
>>>>    ??? link/none
>>>>    ??? inet 10.1.0.99/24 scope global wg0
>>>>    ?????? valid_lft forever preferred_lft forever
>>>> peer:
>>>> 14: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8920 qdisc
>>>> noqueue state UNKNOWN group default qlen 1000
>>>>    ??? link/none
>>>>    ??? inet 10.1.0.100/24 scope global wg0
>>>>    ?????? valid_lft forever preferred_lft forever
>>>>
>>>> This a wg0's IP.
>>>> Someone could shed a bit more light on that - I'd imagine
>>>> many will appreciate, I will.
>>>> I'm thinking - is my ipcalcing messed up..
>>>> many thanks, L.
>>>>   
>>>   
>> Apparently the list (maintainers?) practice old & healthy
>> habit - which placing replies below/at bottom also is -? to
>> accept only "text" format for a message. (I presume for new
>> message/thread)
>> Test that if you will. (Thunderbird works)
>> regards, L.
> Thanks, but I have a text-only mail client. So I don't think that's
> the reason why my posts are still pending. All HTML emails I receive are
> automatically converted for example.
>
>
Perhaps checking settings at - 
https://lists.zx2c4.com/mailman/listinfo/wireguard - is also 
worth checking.
Nothing else comes to mind - I've just double-checked: if I 
leave it to Thunderbird (default format is "automatic") then 
a "failure notice" bounces back to me, whereas "text" 
manually went in.

From peljasz at yahoo.co.uk  Thu Jun  8 12:11:31 2023
From: peljasz at yahoo.co.uk (lejeczek)
Date: Thu, 8 Jun 2023 14:11:31 +0200
Subject: TEXT test - ignore
References: <1f6ed0fe-3eea-38af-0610-b6f2b0f1cbb2.ref@yahoo.co.uk>
Message-ID: <1f6ed0fe-3eea-38af-0610-b6f2b0f1cbb2@yahoo.co.uk>

ignore

From rm at romanrm.net  Mon Jun 26 14:53:11 2023
From: rm at romanrm.net (Roman Mamedov)
Date: Mon, 26 Jun 2023 19:53:11 +0500
Subject: WireGuard IRQ distribution
In-Reply-To: <CA+FoirDk8ZC09YXC7T6ureaBWG6ZREpfE3cq5MoAkKf-rC=U1g@mail.gmail.com>
References: <CA+FoirDk8ZC09YXC7T6ureaBWG6ZREpfE3cq5MoAkKf-rC=U1g@mail.gmail.com>
Message-ID: <20230626195311.03e86a19@nvm>

On Tue, 9 May 2023 15:17:00 -0700
Rumen Telbizov <rumen.telbizov at menlosecurity.com> wrote:

> Baseline iperf3 performance over plain VLAN:
> * Stable 24Gbit/s and 2Mpps
> 
> bmon:
>   Gb                      (RX Bits/second)
> 24.54 .........|.||..|.||.||.||||||..||.||.......................
> 20.45 .........|||||||||||||||||||||||||||||.....................
> 16.36 ........||||||||||||||||||||||||||||||.....................
> 12.27 ........||||||||||||||||||||||||||||||.....................
> 8.18 ........|||||||||||||||||||||||||||||||.....................
> 4.09 ::::::::|||||||||||||||||||||||||||||||:::::::::::::::::::::
>      1   5   10   15   20   25   30   35   40   45   50   55   60
>    M                     (RX Packets/second)
> 2.03 .........|.||..|.||.||.||||||..||.||........................
> 1.69 .........|||||||||||||||||||||||||||||......................
> 1.35 ........||||||||||||||||||||||||||||||......................
> 1.01 ........||||||||||||||||||||||||||||||......................
> 0.68 ........|||||||||||||||||||||||||||||||.....................
> 0.34 ::::::::|||||||||||||||||||||||||||||||:::::::::::::::::::::
>      1   5   10   15   20   25   30   35   40   45   50   55   60
> 
> top:
> %Cpu0  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> %Cpu1  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> %Cpu2  :  1.0 us,  1.0 sy,  0.0 ni, 98.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> %Cpu3  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> %Cpu4  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> %Cpu5  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> %Cpu6  :  1.0 us,  0.0 sy,  0.0 ni, 99.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> %Cpu7  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> %Cpu8  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> %Cpu9  :  1.0 us,  1.0 sy,  0.0 ni, 98.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> %Cpu10 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> %Cpu11 :  0.0 us,  0.9 sy,  0.0 ni, 16.8 id,  0.0 wa,  0.0 hi, 82.2 si,  0.0 st
> %Cpu12 :  0.0 us, 32.3 sy,  0.0 ni, 65.6 id,  0.0 wa,  0.0 hi,  2.1 si,  0.0 st
> %Cpu13 :  1.0 us, 36.3 sy,  0.0 ni, 59.8 id,  0.0 wa,  0.0 hi,  2.9 si,  0.0 st
> %Cpu14 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> %Cpu15 :  0.0 us,  1.0 sy,  0.0 ni, 99.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> 
> The IRQs do pile up behind CPU 11 because iperf3 is single-threaded.

I'm not sure if they pile up because of that, or because of the same reason
you point in WG's case, the 5-tuple being the same for the single TCP
connection of iperf3.

Out of interest, maybe you could try iperf3's UDP mode, and apply the same
port randomization trick as you used for WG, and see if it also makes it see
the better IRQ distribution, and the speed drop?

-- 
With respect,
Roman

From rumen.telbizov at menlosecurity.com  Mon Jun 26 16:18:17 2023
From: rumen.telbizov at menlosecurity.com (Rumen Telbizov)
Date: Mon, 26 Jun 2023 09:18:17 -0700
Subject: WireGuard IRQ distribution
In-Reply-To: <20230626195311.03e86a19@nvm>
References: <CA+FoirDk8ZC09YXC7T6ureaBWG6ZREpfE3cq5MoAkKf-rC=U1g@mail.gmail.com>
 <20230626195311.03e86a19@nvm>
Message-ID: <CA+FoirAsRV2LuEGygz3i4mAWBOAgqWDa6fqcjA8OeDNCZG+a+g@mail.gmail.com>

Hi Roman,

I ran UDP-based iperf and it made no difference.

Thanks for your input

On Mon, Jun 26, 2023 at 7:53?AM Roman Mamedov <rm at romanrm.net> wrote:
>
> On Tue, 9 May 2023 15:17:00 -0700
> Rumen Telbizov <rumen.telbizov at menlosecurity.com> wrote:
>
> > Baseline iperf3 performance over plain VLAN:
> > * Stable 24Gbit/s and 2Mpps
> >
> > bmon:
> >   Gb                      (RX Bits/second)
> > 24.54 .........|.||..|.||.||.||||||..||.||.......................
> > 20.45 .........|||||||||||||||||||||||||||||.....................
> > 16.36 ........||||||||||||||||||||||||||||||.....................
> > 12.27 ........||||||||||||||||||||||||||||||.....................
> > 8.18 ........|||||||||||||||||||||||||||||||.....................
> > 4.09 ::::::::|||||||||||||||||||||||||||||||:::::::::::::::::::::
> >      1   5   10   15   20   25   30   35   40   45   50   55   60
> >    M                     (RX Packets/second)
> > 2.03 .........|.||..|.||.||.||||||..||.||........................
> > 1.69 .........|||||||||||||||||||||||||||||......................
> > 1.35 ........||||||||||||||||||||||||||||||......................
> > 1.01 ........||||||||||||||||||||||||||||||......................
> > 0.68 ........|||||||||||||||||||||||||||||||.....................
> > 0.34 ::::::::|||||||||||||||||||||||||||||||:::::::::::::::::::::
> >      1   5   10   15   20   25   30   35   40   45   50   55   60
> >
> > top:
> > %Cpu0  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> > %Cpu1  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> > %Cpu2  :  1.0 us,  1.0 sy,  0.0 ni, 98.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> > %Cpu3  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> > %Cpu4  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> > %Cpu5  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> > %Cpu6  :  1.0 us,  0.0 sy,  0.0 ni, 99.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> > %Cpu7  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> > %Cpu8  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> > %Cpu9  :  1.0 us,  1.0 sy,  0.0 ni, 98.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> > %Cpu10 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> > %Cpu11 :  0.0 us,  0.9 sy,  0.0 ni, 16.8 id,  0.0 wa,  0.0 hi, 82.2 si,  0.0 st
> > %Cpu12 :  0.0 us, 32.3 sy,  0.0 ni, 65.6 id,  0.0 wa,  0.0 hi,  2.1 si,  0.0 st
> > %Cpu13 :  1.0 us, 36.3 sy,  0.0 ni, 59.8 id,  0.0 wa,  0.0 hi,  2.9 si,  0.0 st
> > %Cpu14 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> > %Cpu15 :  0.0 us,  1.0 sy,  0.0 ni, 99.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
> >
> > The IRQs do pile up behind CPU 11 because iperf3 is single-threaded.
>
> I'm not sure if they pile up because of that, or because of the same reason
> you point in WG's case, the 5-tuple being the same for the single TCP
> connection of iperf3.
>
> Out of interest, maybe you could try iperf3's UDP mode, and apply the same
> port randomization trick as you used for WG, and see if it also makes it see
> the better IRQ distribution, and the speed drop?
>
> --
> With respect,
> Roman

From adrian.popa.gh at gmail.com  Tue Jun 27 12:02:15 2023
From: adrian.popa.gh at gmail.com (Adrian Popa)
Date: Tue, 27 Jun 2023 15:02:15 +0300
Subject: Make error on extract-handshakes
Message-ID: <CAOKso16oBQ+kOS87pGOpAgBZDgQo1gohFMaiyL+AOG1bYY7szA@mail.gmail.com>

Hello everyone!
This is the 4th time I'm trying to post this to the list - the other
messages got held up.

I'm trying to do packet capturing of wireguard traffic and have it
decrypted by Wireshark (for educational purposes), so I'm trying to
compile extract-handshakes with the following commands:

$  git clone https://git.zx2c4.com/WireGuard
$  cd WireGuard/contrib/examples/extract-handshakes
$  make
make -C /lib/modules/6.0.8-060008-generic/build
M=/home/adrianp/temp/extract/WireGuard/contrib/examples/extract-handshakes
offset-finder.o
make[1]: Entering directory '/usr/src/linux-headers-6.0.8-060008-generic'
warning: the compiler differs from the one used to build the kernel
  The kernel was built by: x86_64-linux-gnu-gcc-12 (Ubuntu
12.2.0-9ubuntu1) 12.2.0
  You are using:           gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0
make[3]: *** No rule to make target
'/home/adrianp/temp/extract/WireGuard/contrib/examples/extract-handshakes/offset-finder.o'.
Stop.
make[2]: *** [scripts/Makefile.build:440: __build] Error 2
make[1]: *** [Makefile:1858:
/home/adrianp/temp/extract/WireGuard/contrib/examples/extract-handshakes]
Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.0.8-060008-generic'
make: *** [Makefile:14: offset-finder.o] Error 2

Any ideas what I'm doing wrong? Is this the correct repository for
extract-handshakes? Do I need other steps before make?

My build environment looks ok as far as I can tell:
$  ls -l /lib/modules/6.0.8-060008-generic/build
lrwxrwxrwx 1 root root 43 Nov 10  2022
/lib/modules/6.0.8-060008-generic/build ->
/usr/src/linux-headers-6.0.8-060008-generic

Thanks for your input!

From krose at krose.org  Fri Jun 30 13:04:14 2023
From: krose at krose.org (Kyle Rose)
Date: Fri, 30 Jun 2023 13:04:14 -0000
Subject: Option to enable policy routing
Message-ID: <CAJU8_nVZW5TiDrT-_bmn+DirbfCn4yuHtZi2xjJ+1ZRDi7ME1g@mail.gmail.com>

I really like the straightforward configurability of Wireguard
out-of-the-box. It was astonishingly easy to configure a mesh to
replace my previous hub-and-spoke OpenVPN setup. Thank you for making
this easy.

That said, I'd like the ability to use Linux's policy routing engine
to allow for more complex packet flows across the VPN that are
currently incompatible with Wireguard's internal packet handling. For
example, let's say I have 4 nodes and want to be able to use each of
the nodes as the default gateway for different types of flows.
Modifying the sender side to respect a route's gateway is
straightforward:

--- a/drivers/net/wireguard/allowe
dips.c
+++ b/drivers/net/wireguard/allowe
dips.c
@@ -6,6 +6,8 @@
 #include "allowedips.h"
 #include "peer.h"

+#include <net/route.h>
+
 enum { MAX_ALLOWEDIPS_BITS = 128 };

 static struct kmem_cache *node_cache;
@@ -356,10 +358,18 @@ int wg_allowedips_read_node(struct
allowedips_node *node, u8 ip[16], u8 *cidr)
 struct wg_peer *wg_allowedips_lookup_dst(struct allowedips *table,
                                         struct sk_buff *skb)
 {
-       if (skb->protocol == htons(ETH_P_IP))
-               return lookup(table->root4, 32, &ip_hdr(skb)->daddr);
-       else if (skb->protocol == htons(ETH_P_IPV6))
-               return lookup(table->root6, 128, &ipv6_hdr(skb)->daddr);
+       struct rtable *rt = skb_rtable(skb);
+       if (rt->rt_uses_gateway) {
+               if (rt->rt_gw_family == AF_INET)
+                       return lookup(table->root4, 32, &rt->rt_gw4);
+               else if (rt->rt_gw_family == AF_INET6)
+                       return lookup(table->root6, 128, &rt->rt_gw6);
+       } else {
+               if (skb->protocol == htons(ETH_P_IP))
+                       return lookup(table->root4, 32, &ip_hdr(skb)->daddr);
+               else if (skb->protocol == htons(ETH_P_IPV6))
+                       return lookup(table->root6, 128, &ipv6_hdr(skb)->daddr);
+       }
        return NULL;
 }

The problem is that reply packets will be dropped via the source
address check for all but the peer with the default route listed in
AllowedIPs. The way the trie code works means a highly-invasive change
would be needed to allow for multiple peers to be associated with a
given prefix: I suspect any further complication (not to mention
possible additional data structure bloat) is undesirable, and anyway I
am looking to bypass most of the complexity created by Wireguard's
parallel packet routing infrastructure and instead leverage the far
more flexible Linux policy routing engine.

At this point, what I'd like to do is be able to skip the source
address check by configuration, instead relying on rp_filter and
firewall rules to reject bogus or unwanted packets. With such a config
knob, AllowedIPs would be used only for selecting the destination peer
based on the packet daddr or the route's gateway. For a mesh like I
described above, I would configure only a gateway IP for each peer in
AllowedIPs and use the policy routing engine for all other packet
routing behavior.

I appreciate that Wireguard works the way it does most likely because
routing is configured differently across the wide variety of devices
it supports (and in some cases may be unavailable to users), so I
don't think the AllowedIPs source address check should be removed by
default; but it would be nice if I could turn it off and rely on other
mechanisms in the kernel that would allow for more flexibility.

Thoughts?

Thanks,
Kyle

From news at helweg.eu  Fri Jun  9 14:25:02 2023
From: news at helweg.eu (news at helweg.eu)
Date: Fri, 09 Jun 2023 14:25:02 -0000
Subject: Updating swift tools version to 5.5?
Message-ID: <20230609142502.40285DF40078@dd47522.kasserver.com>

Hi, 

I'm trying to implement the Wireguard iOS Kit into my own iOS App. I followed the description in the README.md of the wireguard-apple repo.

When I try to add the Swift-Package "https://git.zx2c4.com/wireguard-apple" xCode complains with: 

Invalid manifest (compiled with: ["/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc", "-vfsoverlay", "/var/folders/l6/dvt5060j6qlb9_cr_551vdpw0000gn/T/TemporaryDirectory.41wnnP/vfs.yaml", "-L", "/Applications/Xcode.app/Contents/PlugIns/IDESwiftPackageCore.framework/Versions/A/Frameworks/SwiftPM.framework/SharedSupport/ManifestAPI", "-lPackageDescription", "-Xlinker", "-rpath", "-Xlinker", "/Applications/Xcode.app/Contents/PlugIns/IDESwiftPackageCore.framework/Versions/A/Frameworks/SwiftPM.framework/SharedSupport/ManifestAPI", "-target", "arm64-apple-macos12.0", "-sdk", "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk", "-swift-version", "5", "-I", "/Applications/Xcode.app/Contents/PlugIns/IDESwiftPackageCore.framework/Versions/A/Frameworks/SwiftPM.framework/SharedSupport/ManifestAPI", "-sdk", "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk", "-package-description-version", "5.3.0", "-Xfrontend", "-serialize-diagnostics-path", "-Xfrontend", "/Users/jens/Library/Caches/org.swift.swiftpm/manifests/ManifestLoading/wireguard-apple.dia", "/Package.swift", "-disallow-use-new-driver", "-o", "/var/folders/l6/dvt5060j6qlb9_cr_551vdpw0000gn/T/TemporaryDirectory.mYqMCN/wireguard-apple-manifest"])

I can see that the iOS and macOS versions have been bumped to v12 and v15 in one of the last commits. 

Shouldn't the swift tools version also be updated to 5.5?  (First line in the Package.swift file).

Best, Jens