| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The command is
wg set <device> [...] transit-netns <pid|file-path> [...]
For example:
wg set wg0 transit-netns 1
wg set wg0 transit-netns /proc/1/ns/net
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The user can now use
wg --netns <pid|file-path> <subcommand>
to specify the network namespace in which wg should act. This sets the
attribute WGDEVICE_A_DEV_NETNS_PID or WGDEVICE_A_DEV_NETNS_FD.
In the case of
wg --netns <pid|file-path> show all
we have to try to enter the network namespace because the kernel
interface does not allow us to list devices in a network namespace
referenced by pid or fd. Since entering a network namespace requires
CAP_SYS_ADMIN in the current user namespace and the target user
namespace, this is almost useless. TODO: Add the missing functionality
to the kernel.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds two new attributes of which at most one may be
provided:
* WGDEVICE_A_TRANSIT_NETNS_PID: NLA_U32
* WGDEVICE_A_TRANSIT_NETNS_FD: NLA_U32
The transit namespace is then set to this namespace. The caller must
either be in this namespace or have CAP_NET_ADMIN in it.
|
| |
|
|
|
|
|
| |
This eliminates the need for have_transit_net_ref because
have_transit_net_ref == true if and only if dev_net != transit_net.
|
| |
|
|
|
|
|
|
| |
To interact with the UDP socket the caller must either be in the
network namespace of the socket or have CAP_NET_ADMIN in that network
namespace.
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds two new attributes of which at most one may be
provided:
* WGDEVICE_A_DEV_NETNS_PID: NLA_U32
* WGDEVICE_A_DEV_NETNS_FD: NLA_U32
The Wireguard device is then looked up in this namespace instead of the
namespace of the netlink socket.
|
| |
|
| |
|
|
|
|
|
|
| |
This causes RAP to be unhappy, and we're not using it anyway.
Reported-by: Ivan J. <parazyd@dyne.org>
|
|
|
|
| |
This is a follow up of bcf8684c9ec90fe0d283a67d1654d05fb3eae019.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has been fixed upstream. To keep this hack working for toolchains
that don't have it, use CONFIG_CLANG_VERSION, which was added in commit
469cb7376c06 ("kconfig: add CC_IS_CLANG and CLANG_VERSION"), introduced
in 4.18. I have added the '!defined(CONFIG_CLANG_VERSION)' to keep the
hack around for Android. Most custom kernel developers are using AOSP's
Clang, which currently does not have the fix and might not for a while
(although it is probably on Google's mind given that it has been an
issue for ChromeOS on 4.19: https://crbug.com/897215).
I have verified this change against my Pixel 2 kernel and 4.20-rc3 with
the latest ToT Clang.
Link: https://github.com/ClangBuiltLinux/linux/issues/7
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
|
| |
|
| |
|
|
|
|
|
| |
We also move to .SECONDARY, since older kernels don't use targets like
that.
|
| |
|
| |
|
|
|
|
|
|
|
| |
These don't help us, but it is important to keep this working for when
it's re-added to cryptogams.
Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
|
| |
|
|
|
|
|
|
|
|
| |
The original hardcodes returns as .byte 0xf3,0xc3, aka "rep ret".
We replace this by "ret". "rep ret" was meant to help with AMD K8
chips, cf. http://repzret.org/p/repzret. It makes no sense to
continue to use this kludge for code that won't even run on ancient
AMD chips.
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
|
|
|
|
| |
Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
|
|
|
|
| |
Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
|
|
|
|
|
|
| |
We don't need to do this for kernel purposes, but it's polite to leave things unbroken.
Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
|
|
|
|
|
|
| |
objtool did not quite understand the stack arithmetic employed here.
Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
|
|
|
|
|
|
| |
This effectively means swapping the usage of %r9 and %r10 globally.
Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
|
|
|
|
| |
Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
|
|
|
|
| |
Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
|
|
|
|
| |
Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
|
|
|
|
|
|
| |
While Andy is right to desire a separation between compiler defines and
project defines, there are simply too many odd kernel configurations and
we require testing for CONFIG_KERNEL_MODE_NEON.
|
|
|
|
|
| |
We also separate out Eric Biggers' Cortex A7 implementation into its own
file.
|
| |
|
|
|
|
| |
Reported-by: Samuel Holland <samuel@sholland.org>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm using GRE tunnel (transparent Ethernet bridging flavor) over
WireGuard interface to be able to bridge L2 network segments. The
typical protocol chain looks like this IP->GRE->EthernetHeader->IP->UDP.
UDP here is the packet sent from the L2 network segment which is
tunneled using GRE over Wireguard. Indeed, there is a checksum inside
UDP header which is, as a rule, kept partially calculated while packet
travels through network stack and outer protocols are added until the
packet reaches WG device which exposes NETIF_F_HW_CSUM feature meaning
it can handle checksum offload for all protocols.
But the problem here is that skb_checksum_setup called from
encrypt_packet handles only TCP/UDP protocols under top level IP, but in
my case there is a GRE protocol there, so skb_checksum_help is not
called and packet continues its life with unfinished (broken) checksum
and gets encrypted as-is. When such packet is received by other side and
reaches L2 networks it's seen there with a broken checksum inside the
UDP header.
The fact that Wireguard on the receiving side sets skb->ip_summed to
CHECKSUM_UNNECESSARY partially mitigates the problem by telling network
stack on the receiving side that validation of the checksum is not
necessary, so local TCP stack, for example, works fine. But it doesn't
help in situations when packet needs to be forwarded further (sent out
from the box). In this case there is no way we can tell next hop that
checksum verification for this packet is not necessary, we just send it
out with bad checksum and packet gets dropped on the next hop box.
I think the issue of the original code was the wrong usage of
skb_checksum_setup, simply because it's not needed in this case.
Instead, we can just rely on ip_summed skb field to see if partial
checksum needs to be finalized or not. Note that many other drivers in
kernel follow this approach.
In summary:
- skb_checksum_setup can only handle TCP/UDP protocols under top level
IP header, packets with other protocols (like GRE) are sent out by
Wireguard with unfinished partial checksums which causes problems on
receiving side (bad checksums).
- encrypt_packet gets skb prepared by network stack, so there is no need
to setup the checksum from scratch, but just perform hw checksum offload
using software helper skb_checksum_help for packet which explicitly
require it as denoted by CHECKSUM_PARTIAL.
Signed-off-by: Andrejs Hanins <ahanins@gmail.com>
|
|
|
|
| |
This means we do less computation on encapsulated payloads.
|
|
|
|
|
|
|
|
|
|
|
| |
This way other devices that use Android style wakelocks will also have
the same semantics. We also move this logic into the handler so that
it's slightly cleaner and gives us some opportunity to leave a normal
comment.
Suggested-by: Theodore Ts'o <tytso@mit.edu>
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Suggested-by: Sultan Alsawaf <sultanxda@gmail.com>
|