| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
For timers in the hotpath, we don't want them to be rescheduled so
aggressively, and since they don't need to be that precise, we can set a
decent amount of slack.
With the persistent keepalive timer, we have something of a special
case. Since the timeout isn't fixed like the others, we don't want to
make it more often than the kernel ordinarily would. So, instead, we
make it a minimum.
|
| |
|
|
|
|
| |
We sacrifice a little bit of precision here, but this avoids jockeying
around the timers for every packet, when we're sending in bundles anyway
to minimize cache misses.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than only start sending the persistent keepalive packets when the
device first sends data, this changes it to send the packets immediately
on `ip link set up`. This makes things generally seem more stateless,
since the administrator does not have to manually ping the endpoint.
Of course, if you have a lot of peers and all of them have persistent
keepalive enabled, this could cause a lot of unwanted immediate traffic.
On the other hand, if all of those peers are at some point going to be
sending packets, this would happen anyway. I suppose the moral of the
story is that persistent keepalive is a feature really just for clients
behind NAT, not for servers, and it should be used sparingly, which is
why we've set it off by default in the first place.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
It should never be the case that skb->head + skb->transport_header -
skb->data is greater than 2^16, but in case the kernel network stack
borks this at some point in the future, we don't want this to slyly
introduce a vulnerability into WireGuard.
Further, really smart compilers might be able to make deductions about
data_offset, and optimize accordingly.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We don't want people packaging these or even using these scripts, which
are only useful for limited development circumstances, so get rid of
them. More widespread development testing techniques still exist in
src/debug.mk and src/netns.sh
|
| |
|
|
| |
Suggested-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|
| | |
|
| |
|
|
|
| |
For the websites referenced that offer https instead of http, use
https.
|
| | |
|
| |
|
|
|
| |
The padata free functions make reference to their parent workqueue, so
it's important that we wait to free the workqueue after the padata.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per http://lists.openwall.net/netdev/2016/05/03/87 dev->trans_start has
been removed, and updates are now supposed to be handled with
netif_trans_update, which now updates the particular txqueue's
trans_start instead.
However, netdev_start_xmit already updates this member after calling
ndo_start_xmit, so the new netif_trans_update function smartly makes the
comment that for drivers that don't use LLTX, it's not neccessary to
call netif_trans_update.
Except we do use LLTX, so it would seem again that we do need to be
calling netif_trans_update. However, glancing at drivers like vxlan and
other similar virtual tunnels, this doesn't seem to be the case. I
suspect the reason is that we both also set IFF_NO_QUEUE, so we aren't
even using a txqueue for updating.
Thus, this patch removes updating of trans_start all together. I believe
this should be okay for older kernels too.
|
| | |
|
| | |
|
| |
|
|
|
| |
With packets hitting multiple cores, a 64bit backtrack was too small.
This algorithm increases our backtrack to 1984bits.
|
| |
|
Jason A. Donenfeld
Daniel Kahn Gillmor