mirror of
https://github.com/amnezia-vpn/amneziawg-linux-kernel-module.git
synced 2026-10-14 05:41:56 +00:00
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
amnezia-vpn/amneziawg-linux-kernel-module#125
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @VaisVaisov on GitHub (Aug 17, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/issues/216
Environment
1.0.0-0~202608140352+4680320~ubuntu24.04.1(from ppa:amnezia/ppa)1.0.20210914-0~202608130144+ee0f0a9~ubuntu24.04.1(same PPA)Summary
awg setconffails withUnable to modify interface: Invalid argumentwhenHeaderProtectionKeyis present, even though S1-S4 are all well aboveHEADER_PROTECTION_NONCE_SIZE(12) — so this doesn't look like the already-fixed #200/#203 case (missing/too-small S values).Bisection
awg-quick upsucceeds cleanlyawg genpsk, verified 32 bytes after base64 decode)awg-quick upfails:Unable to modify interface: Invalid argumentNotable: userspace implementation is unaffected
Applying the exact same failing config (stripped of wg-quick-only fields) via
amneziawg-go+awg setconfon a manually-created interface works without error (exit code 0), andawg showreflects the config correctly. This points to the bug being specific to the kernel module's netlink handling ofWGDEVICE_A_HEADER_PROTECTION_KEY, not a config/tooling issue.Debugging attempted
Enabled dynamic debug (
echo "module amneziawg +p" > .../dynamic_debug/control) and re-ran the failingsetconf. Nonet_dbg_ratelimitedoutput appeared fromnetlink.cindmesg(other files' pr_debug lines, e.g.cookie.c/socket.c/receive.c, do show up indynamic_debug/control, so dynamic debug itself is working —netlink.c's debug lines simply never printed for this failure), so I wasn't able to pin down the exact failing branch from logs alone.Not yet tested
Have not bisected against intermediate commits between
ce16310(last known-good for this server, 2026-08-05) and4680320(2026-08-14, tag v3.1.20260812) to narrow which commit introduced this — happy to help test if useful.