kmod-amneziawg: add AmneziaWG kernel module package by karen07 · Pull Request #30492 · openwrt/packages

karen07 · 2026-09-09T14:23:17Z

AmneziaWG OpenWrt integration — 1/3

This PR adds the kmod-amneziawg package.

It is the first part of a complete AmneziaWG integration for OpenWrt:

kmod-amneziawg — kernel module (this PR)
amneziawg-tools — userspace tools
luci-proto-amneziawg — LuCI protocol integration

The related PRs will be linked here once submitted.

Maintenance approach

I maintain the complete integration here:

https://github.com/karen07/amneziawg-openwrt-package

The repository is built around a generator:

https://github.com/karen07/amneziawg-openwrt-package/blob/main/generate.py

The goal is to avoid maintaining a large, manually diverging copy of the
OpenWrt WireGuard integration.

generate.py is the source of truth for the generated packages.

For amneziawg-tools and luci-proto-amneziawg, the generator starts from
the corresponding upstream OpenWrt / LuCI WireGuard packages, performs the
mechanical WireGuard-to-AmneziaWG transformations, and then applies only the
AmneziaWG-specific changes.

For review, the generation process can be stopped at separate stages:

vanilla -> files -> text -> full

This makes it possible to inspect separately:

the original upstream WireGuard/OpenWrt baseline;
file and path renames;
identifier renames;
the actual AmneziaWG-specific delta.

This is intended to make both review and future maintenance easier: when the
OpenWrt or LuCI WireGuard integration changes, the AmneziaWG packages can be
regenerated from the new upstream baseline instead of manually rebasing a
large copied implementation.

kmod-amneziawg/Makefile is also generated by the same script from the pinned
AmneziaWG kernel-module version.

The generator is maintenance and review tooling only. The generated package
files are committed to Git, so OpenWrt does not need the generator at build
time.

Upstream tracking

The generator provides:

./generate.py check

to check whether a newer AmneziaWG kernel-module or tools release is available.

I currently run this check manually on a regular basis (normally daily).
When a new upstream version appears, the script stops and requires the version
change to be reviewed explicitly before regeneration, rather than silently
updating to an unreviewed upstream revision.

AmneziaWG sources are pinned to official upstream release tags.

Build and testing workflow

The repository contains an OpenWrt SDK build workflow and a GitHub Actions
target/subtarget matrix for building the generated packages across OpenWrt
targets.

The same repository can also build and install the packages directly on an
OpenWrt device for local testing.

I use this AmneziaWG OpenWrt integration myself, so it is maintained as a
working deployment rather than only as a packaging experiment.

Previous submissions

This is a renewed attempt to bring AmneziaWG support to OpenWrt, with a focus
on addressing the long-term maintenance and reviewability concerns raised
around previous submissions.

Related previous work:

kmod-amneziawg: add new package #26971 — kmod-amneziawg
amneziawg-tools: add new package #26972 — amneziawg-tools
luci-proto-amneziawg: add new package luci#6986 — previous LuCI integration discussion

The reproducible generation approach is specifically intended to keep the
WireGuard-derived parts synchronized with OpenWrt/LuCI upstream while keeping
the AmneziaWG-specific changes small and auditable.

PR series

Once all parts are submitted, this section will link the complete series:

1/3 kmod-amneziawg — this PR
2/3 amneziawg-tools: add AmneziaWG userspace tools package #30493 —amneziawg-tools
3/3 luci-proto-amneziawg — TODO

stangri · 2026-09-09T19:26:19Z

Thanks for this endeavour, I'm sure it would be appreciated by many OpenWrt users.

FWIW regarding the luci app -- as far as I remember the previous discussions, there was a strong preference from the core team to adjust the luci-app-wireguard to support additional amneziawg options, rather than duplicating the code of the existing app into luci-app-amneziawg.

karen07 · 2026-09-09T19:33:06Z

Thanks, that makes sense, and I agree that avoiding a duplicated LuCI implementation would be preferable.

There is one part I am not yet sure how you would prefer to handle: the existing luci-proto-wireguard backend is not only UI code. Its rpcd helper directly calls wg (wg genkey, wg pubkey, wg show all dump, etc.) and parses the WireGuard dump format.

AmneziaWG uses awg show all dump, and its interface dump contains additional AWG-specific fields between listen_port and fwmark. My current implementation therefore adapts the rpcd backend as well as the UI. For example, the AWG parser reads the additional fields and treats fwmark as the final interface field instead of assuming record[4].

So I think sharing the existing WireGuard LuCI code is possible, and I would actually prefer that if it is acceptable upstream, but it would require making the existing LuCI/rpcd implementation protocol-aware rather than simply adding the AWG options to the WireGuard form.

For example, the common code could select wg vs awg and use the corresponding dump parser depending on the protocol.

Is this roughly the approach the core team had in mind?

Also, what do you think about the overall approach of this integration and the way I am trying to keep the AmneziaWG-specific delta small and reviewable?

BKPepe · 2026-09-09T20:17:27Z

What is different than in the last PR #26971 and others https://github.com/openwrt/packages/pulls?q=is%3Apr+state%3Aclosed+kmod-amneziawg ? 🤔

karen07 · 2026-09-09T20:22:39Z

@BKPepe The main difference is that this time I am submitting the complete integration as a coordinated set of three parts:

kmod-amneziawg
amneziawg-tools
luci-proto-amneziawg

They are maintained together in one repository, and the OpenWrt package sources are generated from the corresponding WireGuard packages in a staged way. This makes the AmneziaWG-specific delta explicit and easier to review.

I also track upstream changes in both WireGuard/OpenWrt and AmneziaWG, so the generated packages can be kept in sync instead of drifting as independent copies.

In addition, I use these packages myself, and around 30 other users are currently using them as well. So far we have not encountered any known issues with the integration.

So compared to the previous PRs, this is intended as a complete, actively used, and maintainable integration rather than separate one-off package submissions.

BKPepe · 2026-09-09T20:27:52Z

Sorry, but from your response I am kinda confused.

For LuCI:

there were 4 attempts as seen here: https://github.com/openwrt/luci/pulls?q=is%3Apr+state%3Aclosed+luci-proto-amneziawg

For packages repository:

for both packages, which you are saying as parts, there were also multiple attempts.

Well, I am not sure how they are maintained in one repository as looking into the PKG_SOURCE_URL, but fine, maybe the AI prompt was not right. Even thought, all previous attempts were complete and actively used as well.

karen07 · 2026-09-09T20:32:14Z

@BKPepe You're right, my previous wording was unclear.

By "maintained together in one repository" I did not mean that the upstream source code of the kernel module and tools lives in the same repository. PKG_SOURCE_URL correctly points to the official AmneziaWG upstream repositories.

What I meant is that I maintain the OpenWrt integration for all three parts in one repository:

kmod-amneziawg
amneziawg-tools
luci-proto-amneziawg

I also did not mean to imply that the previous attempts were incomplete or unused. I understand that there were several complete attempts before.

The main difference in my approach is the maintenance model. The OpenWrt packages are generated from the corresponding WireGuard packages in stages, so I can regularly track changes in the OpenWrt WireGuard implementation and keep the AmneziaWG-specific delta small and explicit.

For example, the generation process separates:

the vanilla WireGuard package state,
file/name renaming,
mechanical identifier changes,
the actual AmneziaWG-specific changes.

This makes it easier for me to see what really differs from WireGuard and to update the packages when either OpenWrt WireGuard or AmneziaWG changes.

So the difference I was trying to describe is not that this is the first complete or actively used attempt, but rather that I am trying to provide a reproducible maintenance process for keeping all three parts synchronized over time.

https://github.com/karen07/amneziawg-openwrt-package

https://github.com/karen07/amneziawg-openwrt-package/blob/main/generate.py

https://github.com/karen07/amneziawg-openwrt-package/compare/4b62c027761f554c3bafc28c897df510965eb653..main

karen07 · 2026-09-09T20:35:14Z

@BKPepe Thanks for the clarification.

Then I think the most useful question from my side is: what exactly would need to be changed or improved for AmneziaWG support to be acceptable for inclusion in OpenWrt?

There have already been several attempts over the years, so I would really like to understand whether there are still concrete technical or maintenance blockers, and what you would prefer to see addressed.

I am happy to rework the integration if needed. For example, if the preferred approach for LuCI is to share more code with luci-proto-wireguard instead of maintaining a separate copy, I can work in that direction as well.

My goal is not just to submit another version of the same PR, but to understand the upstream expectations and maintain the packages accordingly.

This support is also quite important in practice. AmneziaWG is widely used by people in Russia and other places where ordinary WireGuard traffic may be blocked or filtered, so having the packages available directly from the official OpenWrt repositories would make a significant difference for users.

If there are specific requirements that would make these packages mergeable, please let me know and I will try to address them.

openwrt-ai · 2026-09-10T05:34:51Z

+	FILES:=$(PKG_BUILD_DIR)/$(MAKE_PATH)/amneziawg.ko
+	DEPENDS:= \
+		+kmod-udptunnel4 \
+		+kmod-udptunnel6 \


kmod-udptunnel6 is declared DEPENDS:=@IPV6, so an unconditional dependency makes kmod-amneziawg unselectable on IPv6-disabled builds. Use the conditional form, like kmod-wireguard and kernel/ovpn-dco.

Suggested change

+kmod-udptunnel6 \

+IPV6:kmod-udptunnel6 \

Generated by Claude Code

fixed, thanks

Generated by Claude Code

openwrt-ai · 2026-09-10T05:34:58Z

+
+PKG_BUILD_PARALLEL:=1
+
+MAKE_PATH:=src


The module is built in $(PKG_BUILD_DIR)/src, but PKG_EXTMOD_SUBDIRS is left at its default ., so collect_module_symvers looks for Module.symvers/modules.order in the build-dir root and stores an empty symvers file for this package. Set it too, the way kernel/ovpn-dco and net/batman-adv do.

Suggested change

MAKE_PATH:=src

MAKE_PATH:=src

PKG_EXTMOD_SUBDIRS:=src

Generated by Claude Code

fixed, thanks

Generated by Claude Code

openwrt-ai · 2026-09-10T05:35:04Z

+		+kmod-udptunnel4 \
+		+kmod-udptunnel6 \
+		+kmod-crypto-lib-chacha20poly1305 \
+		+kmod-crypto-lib-curve25519


No AUTOLOAD here, while kmod-wireguard and the other out-of-tree kmods in this feed (kernel/ovpn-dco, net/siit, net/jool) all set one. The v3.1.20260906 sources do carry MODULE_ALIAS_RTNL_LINK / MODULE_ALIAS_GENL_FAMILY, so on-demand probing should work — is omitting AUTOLOAD:=$(call AutoProbe,amneziawg) intentional?

Generated by Claude Code

fixed, thanks

Generated by Claude Code

openwrt-ai · 2026-09-10T05:35:11Z

+	SECTION:=kernel
+	CATEGORY:=Kernel modules
+	SUBMENU:=Network Support
+	TITLE:=AmneziaWG VPN Kernel Module


nit: two things on this block:

SECTION and CATEGORY are already set for every KernelPackage by kernel.mk.

A define KernelPackage/<name> metadata block is indented with two spaces rather than tabs; same for the FILES/DEPENDS lines below.

Suggested change

SECTION:=kernel

CATEGORY:=Kernel modules

SUBMENU:=Network Support

TITLE:=AmneziaWG VPN Kernel Module

SUBMENU:=Network Support

TITLE:=AmneziaWG VPN Kernel Module

Generated by Claude Code

fixed, thanks

Generated by Claude Code

openwrt-ai · 2026-09-10T05:35:17Z

+PKG_VERSION:=3.1.20260906
+PKG_RELEASE:=1
+
+PKG_SOURCE_PROTO:=git


Optional: PKG_SOURCE_PROTO:=git is meant as a last resort when upstream ships no archives, and upstream tags releases here. The usual form in this feed is a tarball plus PKG_HASH, e.g. PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz with PKG_SOURCE_URL:=https://codeload.github.com/amnezia-vpn/amneziawg-linux-kernel-module/tar.gz/v$(PKG_VERSION)?, which also drops PKG_MIRROR_HASH.

Generated by Claude Code

fixed, thanks — solved with the archive/refs/tags/ + PKG_SOURCE_URL_FILE form rather than codeload, which works equally well.

Generated by Claude Code

openwrt-ai · 2026-09-10T05:35:23Z

+include $(TOPDIR)/rules.mk
+include $(INCLUDE_DIR)/kernel.mk
+
+PKG_NAME:=kmod-amneziawg


nit: no other package in this feed carries a kmod- prefix in PKG_NAME or in its directory name — kernel-module packages are named after the source (kernel/ovpn-dco → ovpn-backports, net/batman-adv, kernel/mdio-netlink). PKG_NAME:=amneziawg still produces the kmod-amneziawg package through $(eval $(call KernelPackage,amneziawg)).

Generated by Claude Code

fixed, thanks — solved by renaming both PKG_NAME and the directory to amneziawg.

Generated by Claude Code

openwrt-ai

Reviewed 1 new commit; no new issues found.

Generated by Claude Code

openwrt-ai

Reviewed 1 new commit.

Generated by Claude Code

openwrt-ai · 2026-09-10T16:46:39Z

+PKG_SOURCE_URL:=https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/archive/refs/tags/
+PKG_SOURCE_URL_FILE:=v$(PKG_VERSION).tar.gz
+PKG_HASH:=e32fa46f1b6f9e319c5261f0b0765c3a9261e40cb7c4616fd73500da961a2932
+PKG_BUILD_DIR:=$(BUILD_DIR)/amneziawg-linux-kernel-module-$(PKG_VERSION)


$(BUILD_DIR) is shared by every subtarget of the same arch (ath79/generic and ath79/nand are both mips_24kc), so an out-of-tree module built here is reused against a different kernel and is not removed by make target/linux/clean — which is why kernel.mk defaults kmod build dirs to $(KERNEL_BUILD_DIR). Keep the override under it, as net/jool/Makefile:23 does.

Suggested change

PKG_BUILD_DIR:=$(BUILD_DIR)/amneziawg-linux-kernel-module-$(PKG_VERSION)

PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/amneziawg-linux-kernel-module-$(PKG_VERSION)

Generated by Claude Code

fixed, thanks

Generated by Claude Code

AmneziaWG is a WireGuard-based VPN protocol with additional traffic obfuscation features designed to make VPN traffic harder to identify and block. This package provides the AmneziaWG Linux kernel module for OpenWrt. Signed-off-by: Karen Khachatryan <karen0734@gmail.com>

openwrt-ai

Reviewed 1 new commit; no new issues found.

Generated by Claude Code

karen07 · 2026-09-10T19:47:31Z

@BKPepe @stangri, I fixed all the issues raised by the @openwrt-ai reviewer.

openwrt Bot added Add package not following guidelines labels Sep 9, 2026

karen07 force-pushed the add-kmod-amneziawg branch from 3d46569 to cd182d0 Compare September 9, 2026 14:33

openwrt Bot removed the not following guidelines label Sep 9, 2026

karen07 mentioned this pull request Sep 9, 2026

amneziawg-tools: add AmneziaWG userspace tools package #30493

Open

karen07 force-pushed the add-kmod-amneziawg branch from cd182d0 to 76e0c31 Compare September 9, 2026 16:08

openwrt-ai reviewed Sep 10, 2026

View reviewed changes

karen07 force-pushed the add-kmod-amneziawg branch from 76e0c31 to fd6bca0 Compare September 10, 2026 07:25

openwrt-ai reviewed Sep 10, 2026

View reviewed changes

karen07 force-pushed the add-kmod-amneziawg branch from fd6bca0 to dae00d4 Compare September 10, 2026 11:30

karen07 requested a review from openwrt-ai September 10, 2026 15:00

karen07 changed the title ~~kmod-amneziawg: Add AmneziaWG kernel module package~~ kmod-amneziawg: add AmneziaWG kernel module package Sep 10, 2026

openwrt-ai reviewed Sep 10, 2026

View reviewed changes

karen07 force-pushed the add-kmod-amneziawg branch from dae00d4 to 1d67cff Compare September 10, 2026 17:11

karen07 requested a review from openwrt-ai September 10, 2026 17:12

openwrt-ai reviewed Sep 10, 2026

View reviewed changes

	PKG_BUILD_DIR:=$(BUILD_DIR)/amneziawg-linux-kernel-module-$(PKG_VERSION)
	PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/amneziawg-linux-kernel-module-$(PKG_VERSION)


		PKG_BUILD_PARALLEL:=1

		MAKE_PATH:=src

Uh oh!

Conversation

karen07 commented Sep 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

AmneziaWG OpenWrt integration — 1/3

Maintenance approach

Upstream tracking

Build and testing workflow

Previous submissions

PR series

Uh oh!

stangri commented Sep 9, 2026

Uh oh!

karen07 commented Sep 9, 2026

Uh oh!

BKPepe commented Sep 9, 2026

Uh oh!

karen07 commented Sep 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BKPepe commented Sep 9, 2026

Uh oh!

karen07 commented Sep 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

karen07 commented Sep 9, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

openwrt-ai left a comment

Choose a reason for hiding this comment

Uh oh!

openwrt-ai left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

openwrt-ai left a comment

Choose a reason for hiding this comment

Uh oh!

karen07 commented Sep 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

karen07 commented Sep 9, 2026 •

edited

Loading

karen07 commented Sep 9, 2026 •

edited

Loading

karen07 commented Sep 9, 2026 •

edited

Loading