Re: Long outage when changing private key
Thanks for taking a look, I should have spent 30 more minutes investigating myself. Please see the patch set I just submitted. Resetting the handshake timer is also necessary or else it takes until the expiration of that timer to actually happen in my setup. It seemed worth putting into a utility function in peers.c, rather than all in netdev.c, so I did that. I checked the preshared key case and that seems to work fine still. ~Derrick ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
[PATCH 2/2] netdev: reset peer keys when changing private key
Without this change, it can take until the handshake timeout period to
reestablish with the peer. After this change, the handshake occurs as soon
as possible and the link is reestablished much more quickly.
Signed-off-by: Derrick Pallas
---
src/netlink.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/netlink.c b/src/netlink.c
index 3458c81..f6b10ad 100644
--- a/src/netlink.c
+++ b/src/netlink.c
@@ -539,6 +539,8 @@ static int wg_set_device(struct sk_buff *skb, struct
genl_info *info)
peer_list) {
if (!wg_noise_precompute_static_static(peer))
wg_peer_remove(peer);
+ else
+ wg_peer_reset_keys(peer);
}
wg_cookie_checker_precompute_device_keys(&wg->cookie_checker);
up_write(&wg->static_identity.lock);
--
2.19.2
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
[PATCH 1/2] peer: add wg_peer_reset_keys
This function will clear the key state for the peer and reset its handshake
timer. This is useful, for instance, if it is known that the current key
material is bad. Currently, this happens when the private key is changed.
Signed-off-by: Derrick Pallas
---
src/peer.c | 14 ++
src/peer.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/src/peer.c b/src/peer.c
index 020a97b..49af31f 100644
--- a/src/peer.c
+++ b/src/peer.c
@@ -87,6 +87,20 @@ struct wg_peer *wg_peer_get_maybe_zero(struct wg_peer *peer)
return peer;
}
+void wg_peer_reset_keys(struct wg_peer *peer)
+{
+ if (unlikely(!peer))
+ return;
+ lockdep_assert_held(&peer->device->device_update_lock);
+
+ wg_noise_handshake_clear(&peer->handshake);
+ wg_noise_keypairs_clear(&peer->keypairs);
+ wg_cookie_checker_precompute_peer_keys(peer);
+ atomic64_set(&peer->last_sent_handshake,
+ ktime_get_boot_fast_ns() -
+ (u64)(REKEY_TIMEOUT + 1) * NSEC_PER_SEC);
+}
+
/* We have a separate "remove" function make sure that all active places where
* a peer is currently operating will eventually come to an end and not pass
* their reference onto another context.
diff --git a/src/peer.h b/src/peer.h
index 2e04262..3800e6f 100644
--- a/src/peer.h
+++ b/src/peer.h
@@ -78,5 +78,6 @@ static inline struct wg_peer *wg_peer_get(struct wg_peer
*peer)
void wg_peer_put(struct wg_peer *peer);
void wg_peer_remove(struct wg_peer *peer);
void wg_peer_remove_all(struct wg_device *wg);
+void wg_peer_reset_keys(struct wg_peer *peer);
#endif /* _WG_PEER_H */
--
2.19.2
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Long outage when changing private key
On Fri, Jan 25, 2019 at 12:59 AM Jason A. Donenfeld wrote:
> @@ -539,6 +539,7 @@ static int wg_set_device(struct sk_buff *skb, struct
> genl_info *info)
> peer_list) {
> if (!wg_noise_precompute_static_static(peer))
> wg_peer_remove(peer);
else
> + wg_noise_keypairs_clear(&peer->keypairs);
> }
> wg_cookie_checker_precompute_device_keys(&wg->cookie_checker);
> up_write(&wg->static_identity.lock);
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Long outage when changing private key
Hi Derrick,
The fix is probably this:
diff --git a/src/netlink.c b/src/netlink.c
index 3458c817..6b6a3f7a 100644
--- a/src/netlink.c
+++ b/src/netlink.c
@@ -539,6 +539,7 @@ static int wg_set_device(struct sk_buff *skb, struct
genl_info *info)
peer_list) {
if (!wg_noise_precompute_static_static(peer))
wg_peer_remove(peer);
+ wg_noise_keypairs_clear(&peer->keypairs);
}
wg_cookie_checker_precompute_device_keys(&wg->cookie_checker);
up_write(&wg->static_identity.lock);
But the idea was originally that we wouldn't clear transport sessions
when the private key or peer preshared key changes, to allow for various
types of negotiated rotations with a grace period, in particular the
case of preshared keys for post quantum protocols. However, I can see
how the private key case causes problems for you, since changing the
public key on a peer is akin to removing and adding a different peer,
and so those transport sessions are lost in the process. In other words,
you might have a point.
Regards,
Jason
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Long outage when changing private key
I believe I found a solution to this problem. Will submit a patch once I've done a bit more testing. ~Derrick On 1/24/19 1:22 PM, Derrick Lyndon Pallas wrote: [snip] ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Long outage when changing private key
With two peers, A with persistent keepalive & B without, I am trying to change the private key on peer A. First I update the public key for A at B, then `wg set wg0 private-key ` on A. It takes roughly the length of the persistent keepalive to reestablish pings from B to A. If instead I update the public key for A at B, remove peer B at A, change A's private key, and then re-add peer B at A, I am able to reestablish pings almost immediately. My guess was that there was a timer that needed to be reset when wg_set_device processes WGDEVICE_A_PRIVATE_KEY, but an attempt to reset timers was unsuccessful. I am new to this code and could use some pointers/advice on where to look next. ~Derrick ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
[BUG] iOS client (0.0.20190107) sometimes kills WiFi connections/switches to LTE
I reported this a few releases ago[1] and it unfortunately it still seems to be affecting the latest iOS app. I found a new wrinkle: if I intentionally add a duplicate profile in the app to my home VPN, the bug is only present when I connect to the first profile. When the bug is triggered (ie the iPhone's icon for WiFi disappears and the LTE icon appears), I can disconnect from the first profile in the app, and then connect to the 2nd profile in the app, and I appear to be back on WiFi using the VPN. 1. https://lists.zx2c4.com/pipermail/wireguard/2018-November/003588.html ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Build error on ARM device due to ld flags
On Thu, Jan 24, 2019 at 4:40 AM Sebastian Gottschall wrote: > > the kernel makefiles used for building on different architectures can be > very different. (see kernel sourcdir/arch/arm/Makefile or arch/x86/Makefile) > so some of them might also overwrite existing flags. what makes me wonder The Makefile you mentioned for this system would seem to be /usr/lib/modules/3.16.62-1-ARCH/build/arch/arm64/Makefile % grep FLAG /usr/lib/modules/3.16.62-1-ARCH/build/arch/arm64/Makefile LDFLAGS_vmlinux :=-p --no-undefined -X CPPFLAGS_vmlinux.lds = -DTEXT_OFFSET=$(TEXT_OFFSET) OBJCOPYFLAGS :=-O binary -R .note -R .note.gnu.build-id -R .comment -S GZFLAGS :=-9 LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name) KBUILD_CFLAGS += -mgeneral-regs-only KBUILD_CFLAGS += $(call cc-option, -mpc-relative-literal-loads) KBUILD_CPPFLAGS += -mbig-endian KBUILD_CPPFLAGS += -mlittle-endian CHECKFLAGS += -D__aarch64__ KBUILD_CFLAGS_MODULE += -mcmodel=large KBUILD_CFLAGS_MODULE += $(call cc-option, -mpc-relative-literal-loads) export TEXT_OFFSET GZFLAGS I actually don't see a plain LDFLAGS in it... just LDFLAGS_vmlinux. > according to your build log you're setting various flags before > entering the wireguard dir and compiling. > why? The packager on Arch (makepkg) has a config file (/etc/makepkg.conf) that is read when a package is built by it which sets the build flags. I just exported the flags therein on the shell then built manually to keep it simple (ie without explaining about the packager). I can tell you that I get the identical error when I build manually as shown or with the packager. Curiously, I only get this error when I build Wireguard on this platform (again reading from /etc/makepkg.conf which sets those flags). I can build anything else without the error (linux kernel, ffmpeg, owncloud, nginx, etc.) > Am 24.01.2019 um 09:57 schrieb John: > > Thank you for the reply. What is odd is that I can build just fine on > > Arch x86_64 which uses the identical LDFLAGS. In any case, is your > > recommendation to drop the -Wl portion of the LDFLAGS or so unset all > > ie: > > > > unset CPPFLAGS CFLAGS CXXFLAGS LDFLAGS DEBUG_CFLAGS DEBUG_CXXFLAGS > > > > On Wed, Jan 23, 2019 at 11:02 PM Sebastian Gottschall > > wrote: > >> -Wl etc is not a valid linker flag, its a flag for gcc which passes the > >> following flags to the linker. so basicly the LDFLAGS are just wrong. > >> in general no CFLAGS or LDFLAGS should be overriden, since wireguard > >> uses exact he same flags which is used for compiling the kernel. so setting > >> custom flags should be avoided > >> > >> Am 23.01.2019 um 22:07 schrieb John: > >>> I am running Arch ARM (aarch64) on an ODROID-C2 using gcc v8.2.1. > >>> Arch ARM which ships with the following LDFLAGS as defaults, > >>> "-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" > >>> > >>> When I build wireguard on this device as shown below, I get this error > >>> but am unsure why: > >>> > >>> ld: unrecognized option > >>> '-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' > >>> ld: use the --help option for usage information > >>> make[2]: *** [scripts/Makefile.build:393: > >>> /scratch/WireGuard-0.0.20190123/src/wireguard.o] Error 1 > >>> make[1]: *** [Makefile:1358: > >>> _module_/scratch/WireGuard-0.0.20190123/src] Error 2 > >>> make: *** [Makefile:36: module] Error 2 > >>> > >>> If I remove the '-Wl' switch from the distro default, it builds > >>> without error. Any advice is appreciated. > >>> > >>> Complete build log and my FLAGS: > >>> > >>> % export CPPFLAGS="-D_FORTIFY_SOURCE=2" > >>> % export CFLAGS="-march=armv8-a -O2 -pipe -fstack-protector-strong > >>> -fno-plt" > >>> % export CXXFLAGS="-march=armv8-a -O2 -pipe -fstack-protector-strong > >>> -fno-plt" > >>> % export LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" > >>> % export DEBUG_CFLAGS="-g -fvar-tracking-assignments" > >>> % export DEBUG_CXXFLAGS="-g -fvar-tracking-assignments" > >>> > >>> % cd WireGuard-0.0.20190123 > >>> % make -j5 -C src > >>> make: Entering directory '/scratch/WireGuard-0.0.20190123/src' > >>> CC /scratch/WireGuard-0.0.20190123/src/tools/wg.o > >>> CC /scratch/WireGuard-0.0.20190123/src/tools/config.o > >>> CC /scratch/WireGuard-0.0.20190123/src/tools/show.o > >>> CC /scratch/WireGuard-0.0.20190123/src/tools/terminal.o > >>> CC /scratch/WireGuard-0.0.20190123/src/tools/ipc.o > >>> CC /scratch/WireGuard-0.0.20190123/src/tools/mnlg.o > >>> CC /scratch/WireGuard-0.0.20190123/src/tools/encoding.o > >>> CC /scratch/WireGuard-0.0.20190123/src/tools/curve25519.o > >>> CC /scratch/WireGuard-0.0.20190123/src/tools/setconf.o > >>> CC /scratch/WireGuard-0.0.20190123/src/tools/genkey.o > >>> CC /scratch/WireGuard-0.0.20190123/src/tools/showconf.o > >>> CC /scratch/WireGuard-0.0.20190123/src/tools/pubkey.o > >>> CC /scratch/WireGuard-0.0.20190123/src/tools/set.o > >>> CC [M]
Re: Build error on ARM device due to ld flags
Thank you for the reply. What is odd is that I can build just fine on Arch x86_64 which uses the identical LDFLAGS. In any case, is your recommendation to drop the -Wl portion of the LDFLAGS or so unset all ie: unset CPPFLAGS CFLAGS CXXFLAGS LDFLAGS DEBUG_CFLAGS DEBUG_CXXFLAGS On Wed, Jan 23, 2019 at 11:02 PM Sebastian Gottschall wrote: > > -Wl etc is not a valid linker flag, its a flag for gcc which passes the > following flags to the linker. so basicly the LDFLAGS are just wrong. > in general no CFLAGS or LDFLAGS should be overriden, since wireguard > uses exact he same flags which is used for compiling the kernel. so setting > custom flags should be avoided > > Am 23.01.2019 um 22:07 schrieb John: > > I am running Arch ARM (aarch64) on an ODROID-C2 using gcc v8.2.1. > > Arch ARM which ships with the following LDFLAGS as defaults, > > "-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" > > > > When I build wireguard on this device as shown below, I get this error > > but am unsure why: > > > > ld: unrecognized option '-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' > > ld: use the --help option for usage information > > make[2]: *** [scripts/Makefile.build:393: > > /scratch/WireGuard-0.0.20190123/src/wireguard.o] Error 1 > > make[1]: *** [Makefile:1358: > > _module_/scratch/WireGuard-0.0.20190123/src] Error 2 > > make: *** [Makefile:36: module] Error 2 > > > > If I remove the '-Wl' switch from the distro default, it builds > > without error. Any advice is appreciated. > > > > Complete build log and my FLAGS: > > > > % export CPPFLAGS="-D_FORTIFY_SOURCE=2" > > % export CFLAGS="-march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt" > > % export CXXFLAGS="-march=armv8-a -O2 -pipe -fstack-protector-strong > > -fno-plt" > > % export LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" > > % export DEBUG_CFLAGS="-g -fvar-tracking-assignments" > > % export DEBUG_CXXFLAGS="-g -fvar-tracking-assignments" > > > > % cd WireGuard-0.0.20190123 > > % make -j5 -C src > > make: Entering directory '/scratch/WireGuard-0.0.20190123/src' > >CC /scratch/WireGuard-0.0.20190123/src/tools/wg.o > >CC /scratch/WireGuard-0.0.20190123/src/tools/config.o > >CC /scratch/WireGuard-0.0.20190123/src/tools/show.o > >CC /scratch/WireGuard-0.0.20190123/src/tools/terminal.o > >CC /scratch/WireGuard-0.0.20190123/src/tools/ipc.o > >CC /scratch/WireGuard-0.0.20190123/src/tools/mnlg.o > >CC /scratch/WireGuard-0.0.20190123/src/tools/encoding.o > >CC /scratch/WireGuard-0.0.20190123/src/tools/curve25519.o > >CC /scratch/WireGuard-0.0.20190123/src/tools/setconf.o > >CC /scratch/WireGuard-0.0.20190123/src/tools/genkey.o > >CC /scratch/WireGuard-0.0.20190123/src/tools/showconf.o > >CC /scratch/WireGuard-0.0.20190123/src/tools/pubkey.o > >CC /scratch/WireGuard-0.0.20190123/src/tools/set.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/main.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/device.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/noise.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/peer.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/timers.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/queueing.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/send.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/receive.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/socket.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/hashtables.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/allowedips.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/ratelimiter.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/cookie.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/netlink.o > >CC [M] > > /scratch/WireGuard-0.0.20190123/src/crypto/zinc/chacha20/chacha20.o > >PERLASM > > /scratch/WireGuard-0.0.20190123/src/crypto/zinc/chacha20/chacha20-arm64.S > >CC [M] > > /scratch/WireGuard-0.0.20190123/src/crypto/zinc/poly1305/poly1305.o > >PERLASM > > /scratch/WireGuard-0.0.20190123/src/crypto/zinc/poly1305/poly1305-arm64.S > >CC [M] > > /scratch/WireGuard-0.0.20190123/src/crypto/zinc/chacha20poly1305.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/crypto/zinc/blake2s/blake2s.o > >CC [M] > > /scratch/WireGuard-0.0.20190123/src/crypto/zinc/curve25519/curve25519.o > >LD /scratch/WireGuard-0.0.20190123/src/tools/wg > >CC [M] /scratch/WireGuard-0.0.20190123/src/compat/siphash/siphash.o > >CC [M] /scratch/WireGuard-0.0.20190123/src/compat/dst_cache/dst_cache.o > >CC [M] > > /scratch/WireGuard-0.0.20190123/src/compat/udp_tunnel/udp_tunnel.o > >AS [M] > > /scratch/WireGuard-0.0.20190123/src/crypto/zinc/chacha20/chacha20-arm64.o > >AS [M] > > /scratch/WireGuard-0.0.20190123/src/crypto/zinc/poly1305/poly1305-arm64.o > >LD [M] /scratch/WireGuard-0.0.20190123/src/wireguard.o > > ld: unrecognized option '-Wl,-O1,--
Re: Rohde & Schwarz Adds Emerging WireGuard VPN Protocol to its Deep Packet Inspection (DPI) Software Library, R&S(R) PACE 2
Deep Packet Inspection is the term used to describe detailed inspection of network traffic. A firewall might allow, block, or log traffic based on source or destination IP address. Or it might do so by looking at TCP and UDP headers inside the IP packet frame. Or, the firewall will even look at the payload inside a TCP or UDP packet frame, and that is called Deep Packet Inspection. WireGuard uses UDP, and by looking at the payload of those UDP packets it is trivial to distinguish from other protocols. An experienced network sysadmin could write you a firewall rule that blocks WireGuard in a few minutes. Obfuscation is not a goal of WireGuard, so this not a problem for WireGuard, the project. It will however be a problem for those blocked by this equipment. Like all technology, this DPI equipment is a double-edged sword. Will it be sold to a government so they can block privacy-seeking dissidents from using WireGuard, or will it be sold to an organization that has a more legitimate need to block WireGuard traffic? The solution is to use an obfuscation protocol that encapsulates WireGuard, just like Tor users in censored countries do. Cheers, Fredrik ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Build error on ARM device due to ld flags
the kernel makefiles used for building on different architectures can be very different. (see kernel sourcdir/arch/arm/Makefile or arch/x86/Makefile) so some of them might also overwrite existing flags. what makes me wonder. according to your build log you're setting various flags before entering the wireguard dir and compiling. why? Am 24.01.2019 um 09:57 schrieb John: Thank you for the reply. What is odd is that I can build just fine on Arch x86_64 which uses the identical LDFLAGS. In any case, is your recommendation to drop the -Wl portion of the LDFLAGS or so unset all ie: unset CPPFLAGS CFLAGS CXXFLAGS LDFLAGS DEBUG_CFLAGS DEBUG_CXXFLAGS On Wed, Jan 23, 2019 at 11:02 PM Sebastian Gottschall wrote: -Wl etc is not a valid linker flag, its a flag for gcc which passes the following flags to the linker. so basicly the LDFLAGS are just wrong. in general no CFLAGS or LDFLAGS should be overriden, since wireguard uses exact he same flags which is used for compiling the kernel. so setting custom flags should be avoided Am 23.01.2019 um 22:07 schrieb John: I am running Arch ARM (aarch64) on an ODROID-C2 using gcc v8.2.1. Arch ARM which ships with the following LDFLAGS as defaults, "-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" When I build wireguard on this device as shown below, I get this error but am unsure why: ld: unrecognized option '-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' ld: use the --help option for usage information make[2]: *** [scripts/Makefile.build:393: /scratch/WireGuard-0.0.20190123/src/wireguard.o] Error 1 make[1]: *** [Makefile:1358: _module_/scratch/WireGuard-0.0.20190123/src] Error 2 make: *** [Makefile:36: module] Error 2 If I remove the '-Wl' switch from the distro default, it builds without error. Any advice is appreciated. Complete build log and my FLAGS: % export CPPFLAGS="-D_FORTIFY_SOURCE=2" % export CFLAGS="-march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt" % export CXXFLAGS="-march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt" % export LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" % export DEBUG_CFLAGS="-g -fvar-tracking-assignments" % export DEBUG_CXXFLAGS="-g -fvar-tracking-assignments" % cd WireGuard-0.0.20190123 % make -j5 -C src make: Entering directory '/scratch/WireGuard-0.0.20190123/src' CC /scratch/WireGuard-0.0.20190123/src/tools/wg.o CC /scratch/WireGuard-0.0.20190123/src/tools/config.o CC /scratch/WireGuard-0.0.20190123/src/tools/show.o CC /scratch/WireGuard-0.0.20190123/src/tools/terminal.o CC /scratch/WireGuard-0.0.20190123/src/tools/ipc.o CC /scratch/WireGuard-0.0.20190123/src/tools/mnlg.o CC /scratch/WireGuard-0.0.20190123/src/tools/encoding.o CC /scratch/WireGuard-0.0.20190123/src/tools/curve25519.o CC /scratch/WireGuard-0.0.20190123/src/tools/setconf.o CC /scratch/WireGuard-0.0.20190123/src/tools/genkey.o CC /scratch/WireGuard-0.0.20190123/src/tools/showconf.o CC /scratch/WireGuard-0.0.20190123/src/tools/pubkey.o CC /scratch/WireGuard-0.0.20190123/src/tools/set.o CC [M] /scratch/WireGuard-0.0.20190123/src/main.o CC [M] /scratch/WireGuard-0.0.20190123/src/device.o CC [M] /scratch/WireGuard-0.0.20190123/src/noise.o CC [M] /scratch/WireGuard-0.0.20190123/src/peer.o CC [M] /scratch/WireGuard-0.0.20190123/src/timers.o CC [M] /scratch/WireGuard-0.0.20190123/src/queueing.o CC [M] /scratch/WireGuard-0.0.20190123/src/send.o CC [M] /scratch/WireGuard-0.0.20190123/src/receive.o CC [M] /scratch/WireGuard-0.0.20190123/src/socket.o CC [M] /scratch/WireGuard-0.0.20190123/src/hashtables.o CC [M] /scratch/WireGuard-0.0.20190123/src/allowedips.o CC [M] /scratch/WireGuard-0.0.20190123/src/ratelimiter.o CC [M] /scratch/WireGuard-0.0.20190123/src/cookie.o CC [M] /scratch/WireGuard-0.0.20190123/src/netlink.o CC [M] /scratch/WireGuard-0.0.20190123/src/crypto/zinc/chacha20/chacha20.o PERLASM /scratch/WireGuard-0.0.20190123/src/crypto/zinc/chacha20/chacha20-arm64.S CC [M] /scratch/WireGuard-0.0.20190123/src/crypto/zinc/poly1305/poly1305.o PERLASM /scratch/WireGuard-0.0.20190123/src/crypto/zinc/poly1305/poly1305-arm64.S CC [M] /scratch/WireGuard-0.0.20190123/src/crypto/zinc/chacha20poly1305.o CC [M] /scratch/WireGuard-0.0.20190123/src/crypto/zinc/blake2s/blake2s.o CC [M] /scratch/WireGuard-0.0.20190123/src/crypto/zinc/curve25519/curve25519.o LD /scratch/WireGuard-0.0.20190123/src/tools/wg CC [M] /scratch/WireGuard-0.0.20190123/src/compat/siphash/siphash.o CC [M] /scratch/WireGuard-0.0.20190123/src/compat/dst_cache/dst_cache.o CC [M] /scratch/WireGuard-0.0.20190123/src/compat/udp_tunnel/udp_tunnel.o AS [M] /scratch/WireGuard-0.0.20190123/src/crypto/zinc/chacha20/chacha20-arm64.o AS [M] /scratch/WireGuard-0.0.20190123/src/crypto/zinc/poly1305/poly1305-arm64.o LD [M] /sc
Rohde & Schwarz Adds Emerging WireGuard VPN Protocol to its Deep Packet Inspection (DPI) Software Library, R&S® PACE 2
https://www.businesswire.com/news/home/20190123005355/en/Rohde-Schwarz-Adds-Emerging-WireGuard-VPN-Protocol Can any expert advise on this matter ?___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
