Thanks Jason!
On Mon, Jan 9, 2017 at 8:22 PM, Jason A. Donenfeld wrote:
> I think I'm going to roll with a flags fix instead, like this:
> https://git.zx2c4.com/WireGuard/commit/?id=45bd499f15debb0e2443b15f7ff1d0
> ef93950acc
>
> This should eliminate all portability issues.
>
__
Hey,
Thanks for the nice analysis. At first I was incredulous about the
results, but then I sat down and drew some pictures, and figured out
where the disconnect is. With hole punching, you have each peer
discovering the remote endpoint tuple, and sending an outgoing packet,
which then adjusts the
I think I'm going to roll with a flags fix instead, like this:
https://git.zx2c4.com/WireGuard/commit/?id=45bd499f15debb0e2443b15f7ff1d0ef93950acc
This should eliminate all portability issues.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://
best we don't goto fail by accident.
---
src/tools/ipc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/tools/ipc.c b/src/tools/ipc.c
index 6237961..0e90b3c 100644
--- a/src/tools/ipc.c
+++ b/src/tools/ipc.c
@@ -240,7 +240,7 @@ static int userspace_get_device(struct wgdevi
The C language does not specify the layout behavior of bit-fields. As a
consequence, compilers are free to do interesting things with these
fields, including reorder, split, pick size, etc. In this case, it was
observed that on x64, gcc and clang were using only two bytes between
tx_bytes and num_i
Hi Baptiste,
after seeing
https://wiki.asterisk.org/wiki/display/TOP/NAT+Traversal+Testing
I realized that the connection tracking with its state calculation and
the SNAT port mapping are two different things which don't have to
follow the same rules related to src/dst IP and ports.
This co
On Fri, Jan 6, 2017 at 6:33 AM, Jason A. Donenfeld wrote:
> Hi Peter,
>
> On Thu, Jan 5, 2017 at 12:08 PM, Peter Dolding wrote:
>>> 1. Dynamic IPs.
>>> 2. Both peers behind NAT.
>> That misses one completely
>> 3. Server and Peers both behind NAT. Yes there is a usage case for this
>> one.
>
>
On Mon, Jan 09, 2017 at 12:00:17AM +0100, Jason A. Donenfeld wrote:
> > I merely pointed out that a stateful firewall is similar to a symmetric
> > NAT, that is, both would cause issue with peer roaming.
>
> Are you sure about this for UDP? I did a bunch of tests several months
> ago, and was able
On Sun, Jan 08, 2017 at 11:49:18PM +0100, Jason A. Donenfeld wrote:
> But if it is in the kernel, the decision logic boils down essentially
> to: there's a list of endpoints in a given order. Based on differing
> metrics of success at differing points in time, the list gets
> reordered, and packets
On Sun, Jan 08, 2017 at 08:37:55PM -0600, Samuel Holland wrote:
> Hello,
>
> On 01/08/17 16:49, Jason A. Donenfeld wrote:
> >However, this doesn't shine any light on the hardest problem: how to
> >update the list of addresses in a memory-bounded fashion. Right now,
> >if you receive an encrypted p
Another use case would be circumventing some crazy state backed firewalls
that drop or throttle -mostly UDP- connections having high bandwidths. If
peer is being used as gateway and nameserver resolver, it can be used to
rotate server IPs too; yet another method to bypass kind of blockages.
_
11 matches
Mail list logo
