Hi,
> On 8 Jan 2017, at 23:49, Jason A. Donenfeld wrote:
>
> (send an encrypted out of band non-IP packet
> directly to a peer, for things like autoconfig) could play a nice role
> in this.
This is highly interesting! I should undust my gcc probably.
> One thing that comes to mind is how to
On Mon, Jan 9, 2017 at 9:46 AM, Ameretat Reith wrote:
> 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
On Mon, Jan 9, 2017 at 3:37 AM, Samuel Holland wrote:
> I think there should be a distinction between endpoint addresses
> provided in explicit configuration and those discovered through roaming.
> Presumably, users put those addresses in the configuration file because
> they expect them to be rel
On Mon, Jan 9, 2017 at 10:47 AM, Baptiste Jonglez
wrote:
> This is not what I proposed. Endpoints do not need to be ordered, and you
Sorry, I read too fast evidently. That's a nice suggestion, indeed, of
sending multiple handshakes and seeing which one arrives first. If the
same exact handshake
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.
_
As I mentioned on an earlier thread, a daydream of mine is to use up extra
ipv6 /64s to improve "fair queued" latency and eliminate head of line
blocking for individual flows.
So being able to dedicate an entire /64 as an endpoint
Endpoint=myserver.tld/64:4242
would lead to a major advance over
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 packet, the endpoint of that peer is
updated to the src address of that packet
Thanks for the proposal. Obviously the easiest solution is a userspace
decoupled one, but this might not necessarily be the most desirable.
However, it's possible the upcoming userspace event notification fd
support (epoll on an fd to learn when handshakes happen) and userspace
peer-message support
Hi,
Here is a proposal for handling multiple endpoints for a single Wireguard
peer. This includes handling dual-stack peers (IPv4 and IPv6) but is more
general.
This is something I had discussed with Jason at the beginning of the
project, but we agreed at the time that it was too early for the a
11 matches
Mail list logo
