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(+)
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 ++
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))
>
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)
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
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
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
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,
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 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
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
11 matches
Mail list logo
