Repository navigation
fix: the overlay's MTU is set live, and an old handshake is drift (keel#139, keel#140) - #143
Merged
Merged
Conversation
…el#139, keel#140) keel#139 (N7). After the upgrade to 0.23.13, wg0.conf had MTU = 1280 and the live wg0 kept 1420. Only wg-quick up reads the line: keel spec apply planned nothing, keel diff had no MTU line, and only a reboot or a manual wg-quick down/up fixed it. - keel.network.mtu reads the live MTU (ip link show) and sets it with ip link set dev <interface> mtu N, which restarts nothing. - The live path of keel.network.switch sets the new file's MTU when the interface has another one; with no live MTU, a change of the MTU line is still a bounce, as is a file that drops it. - keel spec apply: a kept file whose interface has another MTU gets the same action, said as drift (keel.system.overlay). - keel network mtu does it for each WireGuard interface that is up, and the package's postinst (debian/keel.postinst) runs it, so an upgrade needs no reboot. A failure is said and never fails the upgrade. - keel diff reports network.overlay.wireguard.mtu: the live MTU against the file's, on the live system. keel#140 (N6, N10). keel diff said "same" for a handshake 8 h old. A last handshake older than 180 s is now drift in keel diff and keel mesh status: WireGuard does a new handshake every 2 minutes while packets flow. The drift says the member does not answer and is unreachable, and no longer tells the operator to run keel mesh sync on it. Tests: unit tests for the MTU read, the live plan, apply, keel network mtu and keel diff; bats for the postinst; on the real wg in a network namespace, wg0 set to 1420 under a file of MTU = 1280: a live change of the peers sets 1280 with no wg-quick, the same interface and the same handshake, and keel network mtu sets it again. Stale handshakes in keel diff and keel mesh status. Version 0.23.15 (#136 holds 0.23.14).
This was referenced Oct 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #139 and #140. Evidence: Keel-Linux/handbook#63, findings N7, N6 and N10.
#139 (N7)
After the upgrade to 0.23.13, wg0.conf had
MTU = 1280and the live wg0 kept 1420. Onlywg-quick upreads the line, so apply planned nothing and diff had no MTU line.keel/network/mtu.py(new): reads the live MTU (ip link show) and sets it withip link set dev <iface> mtu N. This restarts nothing.keel/network/switch.py(live_plan,mtu_line,wg_mtu): the live path sets the new file's MTU when the interface has another one. With no live MTU, a change of the MTU line is still a bounce, as is a file that drops it.keel/system/overlay.py,keel/system/ovstate.py: a kept file whose interface has another MTU gets theip link setaction, said as drift.keel network mtu(keel/cli.py,keel/commands.py) does it for each WireGuard interface that is up. The newdebian/keel.postinstruns it on configure, so an upgrade needs no reboot. A failure is said and never fails the upgrade.keel/diff/handshakes.py(mtu_fields):network.overlay.wireguard.mtu, the live MTU against the file's, on the live system.#140 (N6, N10)
Docs:
docs/apply.md,docs/diff.md,docs/mesh.md. Version 0.23.15 (#136 holds 0.23.14).Tests
tests/test_network_mtu.py(new),tests/test_system_overlay.py,tests/test_diff_handshakes.py,tests/test_mesh_create_status.py.tests/postinst.bats(new), run fromtests/test_hook_bats.py.tests/test_network_overlay_live_netns.py, in "mesh / trixie"): wg0 is set to 1420 under a file ofMTU = 1280. A live change of the peers sets 1280 with no wg-quick, the same interface index and the same handshake. Thenkeel network mtusets 1420 back to 1280.CI
All 23 checks pass.
vip-upgrade / trixiefailed one time (run 38074400820,test_a_the_holder_restarted_as_an_upgrade_does: the VIP dropped for 4.47 s after the holder's try-restart). That test does not use the code of this PR, and the same job also failed one time on main. One rerun of the failed job passed.