AsusWRT-Merlin NG: extending a third-party firmware to routers ASUS skipped
Extends the support of Merlin firmware to more ASUS routers
At a glance
- What is it?
- gnuton's fork of AsusWRT Merlin keeps the original firmware's feature set and adds models that ASUS never shipped, built in the cloud from published GPL sources.
- Who is it for?
- What gnuton's fork offers is narrow and specific: the Merlin feature set, carried to hardware that never got it, in builds assembled by a CI pipeline from source that is public and inspectable. The version families keep that choice honest, because 3006, 3004 and 386 do not cover the same radios and a model listed under one branch says nothing about the other.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 19 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 28, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A Merlin fork for models ASUS never shipped
AsusWRT-Merlin is third-party firmware for ASUS routers, and it is the closest thing this hardware has to a supported alternative to the image the factory ships. The README states plainly that gnuton's builds are intended to support all features present in the original Merlin firmware, and that additional features sometimes appear for specific models. That is the whole premise. Merlin started from a narrow set of ASUS router models and grew slowly; this fork keeps the upstream feature set and widens the model list.
The repository is a fork of RMerl's AsusWRT Merlin, and the README notes it is supported by ASUS and RMerlin. It is written in C, which is what you would expect for a firmware image that has to fit alongside the vendor's own kernel and drivers on hardware with fixed memory budgets. The last commit on the default branch, master, landed on 2026-09-17. Around that time the repository carried 2,335 stars, 137 forks and 370 open issues, a ratio that says as much about the shape of the project as the counts do: people depend on it, they patch their own routers with it, and they file detailed problems against it.
GitHub's license detection returns NOASSERTION for this repository, and the tree carries a plain `License` file next to the readmes rather than a standard SPDX-labeled license file. For firmware derived from vendor GPL drops, that arrangement is typical rather than alarming, but it is worth understanding what it means before you rely on the legal clarity of the code rather than its availability.
Three version families, and why the number matters
The README organizes downloads by firmware generation rather than by a single latest image, and the numbers are not interchangeable. There are three families in the tree of releases: 3006 for WiFi 7 routers, 3004 for WiFi 6, and 386 for the DSL-AC68U. Each family has its own stable release and its own pre-release, and the pre-releases are labeled for advanced users testing new features rather than for everyday use.
The naming convention is inherited from upstream Merlin, where the leading number identifies the underlying ASUS firmware generation and the rest tracks that generation's build. A router supported under 3004 is not automatically supported under 3006, and a build under one family will not flash onto hardware from another. The repository also tracks upstream Merlin releases in parallel, with badge links filtered separately for the 3006 and 3004 lines, so you can see whether a newer upstream version exists that the fork has not merged yet.
Three releases illustrate how the fork absorbs upstream changes. Release 3004.388.11_1-gnuton1, published on 2026-06-10, updated upstream code to 3004.388.11 and merged GPL 388_25575, and it also removed AiCloud support for security reasons. The beta published on 2026-01-30 carries the same three changelog lines. Release 3006.102.6_1-gnuton1 from 2025-12-28 records a single change, an update of upstream GPL 39099 for the GT-BE98.
Read that June changelog carefully before anything else. AiCloud was not a cosmetic removal; it was a vendor cloud account feature, and the reason given is security. A feature disappearing from a fork release is a reminder that these images are maintained by one person balancing upstream merges against risk, and the risk decisions show up in the release notes.
Which hardware the 3006 and 3004 branches actually cover
The WiFi 7 branch, version 3006, currently lists one hardware family: the GT-BE98 and the GT-BE25000. That is a very small surface for the newest generation of ASUS hardware, and it is the single most useful fact on the page for anyone with a recent gaming router.
The WiFi 6 branch, version 3004, is where the model list gets long. It covers the DSL-AX82U and DSL-AX5400, both revisions of the RT-AX82U, the RT-AX92U, TUF-AX5400 v1, TUF-AX3000 v1 and v2, RT-AX58U v2, RT-AX5400, and the ZenWiFi XT8 with its RT-AX95Q v1 equivalent plus the ET8 with RT-AXE95Q. Note the revision qualifiers. V1 and V2 of the same product name are different boards, and the list distinguishes them for a reason.
The 386 branch covers the DSL-AC68U alone, which is also the model name that appears as a repository topic. Beyond the standard images there is an experimental build tagged gnuton-snapshot-feature-repeater that unlocks repeater mode alongside the standard operational modes. The README attaches an important caveat to it: AiMesh is supported by the standard images and performs much better than repeater mode, but it works only with other ASUS routers. Repeater mode makes the hardware work with non-ASUS equipment at the cost of throughput.
Every model list has to be checked against the exact box in front of you, because a model number alone is sometimes ambiguous and a hardware revision inside a revision is sometimes ambiguous on top of that.
Cloud builds and the transparency argument
Firmware images are opaque by nature. You flash a binary onto a device that then controls your network, and the ordinary path gives you a file and no way to trace where it came from. This project takes the opposite position. The README states that the images are built in the cloud to ensure transparency, and that the open-source code is publicly accessible in the repository.
The repository layout supports that claim in a way that is easy to read. There is a `release/` directory, a `scripts/` directory, a `tools/` directory and an `updates/` directory, alongside `Changelog-NG.txt` and several readme variants: `README.md`, `README-merlin.txt`, `README.TXT` and a `README.proprietary`. The `_config.yml` and `AGENTS.md` files at the root are small signs of a repository configured for automated tooling and agent-assisted contributions rather than a manual release ritual.
The acknowledgements section gives the build infrastructure its due. ASUS is credited for the GPL drops and the hardware samples, the upstream Merlin developers are credited for their work, GitHub is credited for providing the infrastructure powering the continuous integration, and CircleCI is credited specifically for its CI infrastructure. Two independent CI providers appearing in one project's credits is an unusual signal: it suggests the release pipeline was not left dependent on a single service.
The practical payoff for a reader is verification. If you intend to run this firmware on a router that handles all your traffic, the ability to trace an image back to a build pipeline is worth more than any individual feature toggle in the web interface.
Identifying the hardware revision before you flash
The README's troubleshooting section answers the question that comes up first for anyone new to this: not sure which version you have? The answer is to enable SSH, connect to the router, and read one value out of its non-volatile RAM.
nvram get productidThat single command returns the product identifier the bootloader stored, which distinguishes a V1 board from a V2 board even when the printed model name is identical. This is the check that separates a supported flash from a bricked router, and it takes about a minute with SSH enabled through the ASUS administration interface.
Everything else about the installation path lives outside the repository. There is no installer script to run and no package to fetch, because the deliverable is a firmware image rather than a program. The README links to the upstream documentation for AsusWRT itself, and the download links point at filtered lists of GitHub releases where the version badge and the download button are generated per family.
Two paths exist for getting help after an install. The README points at a support forum thread on the SNB Forums, a Discord channel, and an issue tracker with separate templates for feature requests and bug reports. There is also a developer document inside the web interface tree at `www/DEV.md`, which is where a contributor would start if they intended to send code rather than report a problem.
What the changelog says about who maintains this
A useful signal when evaluating any firmware fork is whether its release notes say what changed and why. This one does, and the entries are short enough to read in full. Upstream code updates name the upstream version. GPL merges name the specific drop number, as in GPL 388_25575 and GPL 39099. Removals name a feature and a reason, which is more information than most consumer firmware ever provides about a change that affects your configuration.
The same courtesy appears in the README's feature policy. Builds are intended to carry all features of the original Merlin firmware, and model-specific additions are described as occasional rather than as a permanent divergence. That restraint is what keeps the fork mergeable: a wider fork drifts from upstream and gets harder to rebase, and each rebase is where security fixes get delayed.
The project's own support surface is unusual for a firmware fork. Star requests, bug reports, code contributions, chat and support tickets are all listed as ways to help, with a note for developers pointing at the developer document. The download statistics are tracked through a third-party badge service that charts release downloads per tag and in total.
Taken together, the picture is of a project run by a maintainer who treats documentation as part of the deliverable. The open issue count of 370 suggests active use rather than neglect, since abandoned firmware forks accumulate questions that nobody answers, and the September 2026 push date says work is still landing on master.
Editorial conclusion
What gnuton's fork offers is narrow and specific: the Merlin feature set, carried to hardware that never got it, in builds assembled by a CI pipeline from source that is public and inspectable. The version families keep that choice honest, because 3006, 3004 and 386 do not cover the same radios and a model listed under one branch says nothing about the other. Before any flash, the firmware's own advice is the right starting point: read the model list, check the release notes for removed features, and identify the exact hardware revision rather than the marketing name. A router that identifies as the wrong revision is the failure mode that turns a supported model into a brick, and no changelog entry can catch that for you.
Frequently asked questions
What is AsusWRT-Merlin firmware?
AsusWRT-Merlin is third-party firmware for ASUS routers, built as an alternative to the factory image. gnuton's fork at asuswrt-merlin.ng keeps the original Merlin feature set and adds support for router models that ASUS never shipped Merlin on, including several WiFi 6 boards, the ZenWiFi mesh units, and the GT-BE98 on the 3006 WiFi 7 branch.
What can you do with ASUS Merlin?
Within what this repository documents, you run a firmware image whose feature set matches the original Merlin, on models ASUS did not support, with some model-specific additions. It ships as three version families keyed to the vendor firmware generation, each with a stable release for everyday use and a pre-release for testing new features, plus an experimental repeater-mode build for the older hardware.
Should I use AsusWRT-Merlin?
It fits if your exact model and hardware revision appear in the list for one of the three version families, and you are willing to read release notes before flashing. Check that the model is listed rather than the product family, confirm the revision with `nvram get productid` over SSH, and read the changelog for removals. The June 2026 3004 release dropped AiCloud for security reasons, which is the kind of change worth knowing about in advance.
Is ASUS Merlin firmware safe?
The project argues for its own trustworthiness on observable grounds rather than assertion: images are built in the cloud to ensure transparency, the source is publicly accessible in the repository, the GPL drops ASUS provides are merged with their drop numbers named in the changelog, and CI infrastructure from GitHub and CircleCI is credited. It remains third-party firmware maintained independently of ASUS, running on hardware that has no vendor recovery path after a bad flash, so read the notes first.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/gnuton-asuswrt-merlin-ng)