I am curious if any pre-existing code exists for using wireguard like
methods over udp in userspace? Most of the examples for libsodium, etc
are all tcp based. A daemon I'm trying to spec need to run at early
boot (where the clock is wrong and might be slewed forward at any
time), and can't hang.
I've only been using wireguard for 24 hours, and I like it a lot.
In my world, what I'd want is the ability to leverage source specific
routing, and to be able
to have nailed up dozens of routes to the same dozens of locations,
having a routing protocol layered on top to pick the best one (or, in
that + 1 was clever. I think you are done... and I should go change the blog. :)
On Thu, Sep 29, 2016 at 11:59 AM, Jason A. Donenfeld <ja...@zx2c4.com> wrote:
> On Thu, Sep 29, 2016 at 8:19 PM, Dave Taht <dave.t...@gmail.com> wrote:
>> I think the correct behavior h
I have been running a set of tinc based vpns for a long time now, and
based on the complexity of the codebase, and some general flakyness
and slowness, I am considering fiddling with wireguard for a
replacement of it. The review of it over on
My thought - given that at least on some platforms - encrypting 1000
packets at a time is a bad idea - would be something regulating the
amount of data being crypted at a time, an equivalent to byte queue
limits - BQL - BCL? byte crypto limits - to keep no more than, say,
1ms of data in that part
Instruction traps are really bad news on mips. We had to expressly
patch the entire linux kernel stack in the openwrt project to shift to
shorter loads on some arches (because other things come through the
stack, misaligned).
The fix was pretty simple tho, you just declare the relevant struct
I agree that wireguard is potentially a good substrate for what you
describe. There are messy details.
My personal goal is to also get it to do good congestion control
(adding fq_codel) next year while thinking hard about the problems
that tor had in that department.
On Sat, Dec 3, 2016 at
prefeered of 0) this way or hnetd, or
if there was some better way
to deprioritize a given set of ipv6 addrs, but...
Now that I have a whole /56 I can finally fiddle more with hnetd
again. This also gives me cheap failover if one of my gws goes down...
On Thu, Nov 8, 2018 at 3:57 PM Dave Taht wrote:
On Tue, Apr 28, 2020 at 2:10 AM Toke Høiland-Jørgensen wrote:
>
> "Rodney W. Grimes" writes:
>
> > Replying to a single issue I am reading, and really hope I
> > am miss understanding. I am neither a wireguard or linux
> > user so I may be miss understanding what is said.
> >
> > Inline at