| Age | Commit message (Collapse) | Author |
|---|
|
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.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
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.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
The padata free functions make reference to their parent workqueue, so
it's important that we wait to free the workqueue after the padata.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
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.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
With packets hitting multiple cores, a 64bit backtrack was too small.
This algorithm increases our backtrack to 1984bits.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
