| ff78bfe4 | 10-Sep-2025 |
Jason A. Donenfeld <Jason@zx2c4.com> |
wireguard: selftests: select CONFIG_IP_NF_IPTABLES_LEGACY
This is required on recent kernels, where it is now off by default. While we're here, fix some stray =m's that were supposed to be =y.
Sign
wireguard: selftests: select CONFIG_IP_NF_IPTABLES_LEGACY
This is required on recent kernels, where it is now off by default. While we're here, fix some stray =m's that were supposed to be =y.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Link: https://patch.msgid.link/20250910013644.4153708-5-Jason@zx2c4.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
| ca8bf8f3 | 21-May-2025 |
Jason A. Donenfeld <Jason@zx2c4.com> |
wireguard: selftests: specify -std=gnu17 for bash
GCC 15 defaults to C23, which bash can't compile under, so specify gnu17 explicitly.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Link: http
wireguard: selftests: specify -std=gnu17 for bash
GCC 15 defaults to C23, which bash can't compile under, so specify gnu17 explicitly.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Link: https://patch.msgid.link/20250521212707.1767879-6-Jason@zx2c4.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
show more ...
|
| ba3d7b93 | 21-May-2025 |
Jordan Rife <jordan@jrife.io> |
wireguard: allowedips: add WGALLOWEDIP_F_REMOVE_ME flag
The current netlink API for WireGuard does not directly support removal of allowed ips from a peer. A user can remove an allowed ip from a pee
wireguard: allowedips: add WGALLOWEDIP_F_REMOVE_ME flag
The current netlink API for WireGuard does not directly support removal of allowed ips from a peer. A user can remove an allowed ip from a peer in one of two ways:
1. By using the WGPEER_F_REPLACE_ALLOWEDIPS flag and providing a new list of allowed ips which omits the allowed ip that is to be removed. 2. By reassigning an allowed ip to a "dummy" peer then removing that peer with WGPEER_F_REMOVE_ME.
With the first approach, the driver completely rebuilds the allowed ip list for a peer. If my current configuration is such that a peer has allowed ips 192.168.0.2 and 192.168.0.3 and I want to remove 192.168.0.2 the actual transition looks like this.
[192.168.0.2, 192.168.0.3] <-- Initial state [] <-- Step 1: Allowed ips removed for peer [192.168.0.3] <-- Step 2: Allowed ips added back for peer
This is true even if the allowed ip list is small and the update does not need to be batched into multiple WG_CMD_SET_DEVICE requests, as the removal and subsequent addition of ips is non-atomic within a single request. Consequently, wg_allowedips_lookup_dst and wg_allowedips_lookup_src may return NULL while reconfiguring a peer even for packets bound for ips a user did not intend to remove leading to unintended interruptions in connectivity. This presents in userspace as failed calls to sendto and sendmsg for UDP sockets. In my case, I ran netperf while repeatedly reconfiguring the allowed ips for a peer with wg.
/usr/local/bin/netperf -H 10.102.73.72 -l 10m -t UDP_STREAM -- -R 1 -m 1024 send_data: data send error: No route to host (errno 113) netperf: send_omni: send_data failed: No route to host
While this may not be of particular concern for environments where peers and allowed ips are mostly static, systems like Cilium manage peers and allowed ips in a dynamic environment where peers (i.e. Kubernetes nodes) and allowed ips (i.e. pods running on those nodes) can frequently change making WGPEER_F_REPLACE_ALLOWEDIPS problematic.
The second approach avoids any possible connectivity interruptions but is hacky and less direct, requiring the creation of a temporary peer just to dispose of an allowed ip.
Introduce a new flag called WGALLOWEDIP_F_REMOVE_ME which in the same way that WGPEER_F_REMOVE_ME allows a user to remove a single peer from a WireGuard device's configuration allows a user to remove an ip from a peer's set of allowed ips. This enables incremental updates to a device's configuration without any connectivity blips or messy workarounds.
A corresponding patch for wg extends the existing `wg set` interface to leverage this feature.
$ wg set wg0 peer <PUBKEY> allowed-ips +192.168.88.0/24,-192.168.0.1/32
When '+' or '-' is prepended to any ip in the list, wg clears WGPEER_F_REPLACE_ALLOWEDIPS and sets the WGALLOWEDIP_F_REMOVE_ME flag on any ip prefixed with '-'.
Signed-off-by: Jordan Rife <jordan@jrife.io> [Jason: minor style nits, fixes to selftest, bump of wireguard-tools version] Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Link: https://patch.msgid.link/20250521212707.1767879-5-Jason@zx2c4.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
show more ...
|
| b438b3b8 | 02-Aug-2022 |
Jason A. Donenfeld <Jason@zx2c4.com> |
wireguard: selftests: support UML
This shoud open up various possibilities like time travel execution, and is also just another platform to help shake out bugs.
Cc: Johannes Berg <johannes@sipsolut
wireguard: selftests: support UML
This shoud open up various possibilities like time travel execution, and is also just another platform to help shake out bugs.
Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
| b83fdcd9 | 07-Jul-2022 |
Jason A. Donenfeld <Jason@zx2c4.com> |
wireguard: selftests: use microvm on x86
This makes for faster tests, faster compile time, and allows us to ditch ACPI finally.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Ja
wireguard: selftests: use microvm on x86
This makes for faster tests, faster compile time, and allows us to ditch ACPI finally.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
| 1a087eec | 07-Jul-2022 |
Jason A. Donenfeld <Jason@zx2c4.com> |
wireguard: selftests: always call kernel makefile
These selftests are used for much more extensive changes than just the wireguard source files. So always call the kernel's build file, which will do
wireguard: selftests: always call kernel makefile
These selftests are used for much more extensive changes than just the wireguard source files. So always call the kernel's build file, which will do something or nothing after checking the whole tree, per usual.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|