patched my 6.0.28 in /usr/ports/unifi6. make; make deinstall ; make reinstall. I'm on 6.0.41 now, all seems to be working.

In D26137#612131, @grehan wrote:

I'm not seeing those files in 80072.

In D26137#612057, @mmacy wrote:

• more dead code GC
• add header licenses

In D26137#610778, @sg2342_googlemail.com wrote:

moved the test setup to a different machine and after 1 hour and 19 minutes of running the test setup i got a panic here:

Stefan, I'm on r367980 with diff 79843 and I manually removed the mfree line in wg_encap since the latest diff 79919 could not be used. I've run your test for over 6 hours now without any panic. I even added iperf3 --udp and bombarded the server over the wg link for one hour. Only difference what I understand is that i'm on a bare metal server and you run in a bhyve/vale instance. Could what you see now instead be an issue with the virtualization layer?

In D26137#610083, @mmacy wrote:

• fix BPF issue
• avoid socket operations when link is down
• fix use after free

In D26137#607742, @mmacy wrote:

• fix ifwg.c compile
• avoid enqueueing tasks when link is down
• wait for tasks to complete before detach

In D26137#600608, @mmacy wrote:

• rebase
• fix WGC_SET priv_check to work in jails
• mark link down before starting detach

In D26137#597167, @sg2342_googlemail.com wrote:

In order to have working wg in VIMAGE jails:

diff --git a/sys/dev/if_wg/module/module.c b/sys/dev/if_wg/module/module.c
index 6aa4aa52c146..23fda51b4935 100644
--- a/sys/dev/if_wg/module/module.c
+++ b/sys/dev/if_wg/module/module.c
@@ -766,7 +766,7 @@ wg_priv_ioctl(if_ctx_t ctx, u_long command, caddr_t data)
                        return (wgc_get(sc, ifd));
                        break;
                case WGC_SET:
-                       if (priv_check(curthread, PRIV_DRIVER))
+                       if (priv_check(curthread, PRIV_NET_HWIOCTL))
                                return (EPERM);
                        return (wgc_set(sc, ifd));
                        break;

since PRIV_DRIVER is not in the privileges specific to prisons with a virtual network stack.
Or maybe create PRIV_NET_WG after all.

In D26137#596424, @mmacy wrote:

Can you try this patch:

Did not help. Same results as before.

It seems that the new wg interface is not completely jail-ready yet. I'm exposing the wg interface in devfs.rules with
[devfsrules_jail_wg=10]
add include $devfsrules_jail_vnet
add path 'wg*' unhide

In D26137#595828, @mmacy wrote:

• Don't advertise checksum offload

In D26137#587238, @mmacy wrote:

In D26137#586901, @peter_libassi.se wrote:

Bad news, remember https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247853
comment 6 item2 and comment 8. Local access to wg-host services was early an issue, then with D26137 this issue was solved and do still work.

Now i've found as it seems that issue is the other way around, services on a remote host is not accessible. Below my test setup:

bsd1 em0:172.16.0.150/24 --- bsd2 em0:172.16.0.179/24

bsd2 ue0:172.16.42.1/24 ---bsd22 172.16.42.2

bsd1 wg0:192.168.3.1/24 ----- bsd2 wg0:192.168.3.2/24

ping and traceroute works to all IP addresses
bsd1 ssh to bsd2 192.168.3.2 works
bsd1 ssh to bsd2 172.16.42.1 works
bsd1 ssh to bsd22 172.16.42.2 does not work

I tried these routes over wg0, same result:
route add -inet 172.16.42.0/24 192.168.3.2
route add -inet 172.16.42.0/24 -interface wg0

bsd1 ssh to bsd22 works (of course) if I change the route to
route add -inet 172.16.42.0/24 172.16.0.179
i.e no wireguard, instead via local lan em0

tested on r365550 with Diff 76838

I don't understand the description of your setup. Could you please give me the exact steps for reproducing.

Bad news, remember https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247853
comment 6 item2 and comment 8. Local access to wg-host services was early an issue, then with D26137 this issue was solved and do still work.

Hostname in the endpoint directive does not resolve to an IP address:

In D26137#585849, @jim_netgate.com wrote:

In any case, you're seeing 897Mbps, while perfect would be 910Mbps (given my math above) so you're seeing 98.6% of whats possible in-theory.

This should be close enough.

Thanks for the theory session. This helps setting the right expectations.

In D26137#585890, @mmacy wrote:

• fix allowedips in peer-list output

Tested diff 76721 on r365402

tested on r364973