Hi Jason,
> I'd thought of this early on, but failed to come up with what seemed
> like an actually realistic use case for it.
How about creating Wireguard devices as a user that has no
privileges/capabilites in the init namespace?
$ unshare -r -U -m
$ mount --bind /proc/self/ns/net init-ns
$ un
Hi Adrian,
As SIDE_B has a public IP address, the example you give should work fine. In
this case, SIDE_A will establish a connection with SIDE_B which effectively
punches a NAT hole for return traffic from SIDE_B to SIDE_A.
When configuring the SIDE_A peer on SIDE_B, just leave EndPoint unset.
Hi Philipp,
Super ancient kernels like that cannot use Neon in kernel space.
Jason
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
On Fri, Sep 7, 2018 at 1:20 AM Fredrik Strömberg wrote:
> Using Pluggable Transports seem like a good solution. Simply divert
> WireGuard traffic to a local UDP port, which then sends it using a
> Pluggable Transport over the Internet to the other WireGuard peer.
>
> StarBrilliant: You indicated t
Hello Jason,
yes this works indeed thank you!
This means however that NEON SIMD instructions are not used, right ? The
datasheet of the board mentions that it includes the NEON SIMD coprocessor
: https://dn.odroid.com/S805/Datasheet/S805_Datasheet%20V0.8%2020150126.pdf
And CONFIG_NEON=y is activ
