Koolshare rogsoft: a plugin center for modified Asus router firmware

What this repository actually is

The GitHub description is one line: a software center for hnd, axhnd, and axhnd.675x routers. That is accurate but compressed. The README expands it as the software center for the koolshare modified Asus firmware, and states immediately that it is not compatible with the earlier arm380 and arm384 software centers, which are separate projects in the same organisation.

So this is a plugin distribution point, not an application. The tree confirms the shape: about forty directories, one per plugin, alongside `center/`, `koolcenter/`, and `softcenter/` for the software center itself, plus `.gitmodules` and a `checkout-build-files.sh` script that pulls submodule content and shared build files.

Among the plugin directories are `entware/`, `tailscale/`, `zerotier/`, `nodejs/`, `frpc/`, `frps/`, `gostun/`, `natmap/`, `tmux/`, `swap/`, `homeassistant/`, `acme/`, `shiptv/`, `kms/`, `ssserver/`, `fakesip/`, and `fakehttp/`. The names describe the contents, which ranges from ordinary self-hosted infrastructure to proxy tooling and a Windows activation helper. The point is not to endorse or condemn any of them but to note that this is an unrestricted plugin repository rather than a curated one, so a reader choosing what to install is making that call themselves.

The homepage field points at asusgo.com rather than a project site, and there are no release tags at all, so there is no version history to track a plugin through.

Reading the platform tables without guessing

The README carries two tables, one for koolshare's officially modified firmware and one for its Merlin-based fork. Each row is a router model with a link, a CPU or SoC, a platform identifier, an architecture, a kernel version, and a skin name. Reading a row tells you exactly what a plugin author has to satisfy.

The rows are not uniform, and the differences are the interesting part. RT-AC86U appears in both tables with the same BCM4906 SoC, the same hnd platform, and the same 4.1.27 kernel, but with different skins, and a footnote explains why: from firmware version 384_81918 onward that model uses the asuswrt interface rather than the rog one. RT-AX92U and RT-AX68U also change skin between rows. Several models ship only an orange tuf skin, and the README explains that the tuf skin is derived from the rog skin by colour substitution, so a plugin author writing rog-styled interface code has to keep red values replaceable.

The architecture column has an inconsistency worth flagging. Rows on the `axhnd.675x` platform are listed as ARMV7, while rows on `p1axhnd.675x`, which carries the same `.675x` suffix, are listed as ARMV8. The developer's notes then say that armv8 platforms support both 32-bit and 64-bit programs while armv7l platforms on axhnd.675x support only 32-bit, and recommend 32-bit everywhere for compatibility, noting that even on a 64-bit kernel such as RT-AX86U's the userspace programs are almost all 32-bit.

One row has a placeholder rather than a real link: the RT-AX82U entry points at a thread URL containing `xxxxxx` where the identifier would be. If you are looking up that model, the table will not get you to the firmware.

What a plugin author has to build against

The developer section is the most specific part of the README, and it reads like a list of constraints learned the hard way.

The software center API is the 1.5 generation, shared with ledesoft, armsoft, and qcasoft, and it is not compatible with the previous Merlin 380 center because that one used a different web API. Plugins target 32-bit binaries compiled with the Broadcom SDK toolchains: `crosstools-arm-gcc-5.3-linux-4.1-glibc-2.22-binutils-2.25` for the hnd platform and `crosstools-arm-gcc-5.5-linux-4.1-glibc-2.26-binutils-2.28.1` for axhnd. The README adds that binaries built with either toolchain generally run on both platforms, and recommends fully static linking so that they behave the same across firmware versions.

Interface work is where the effort goes. Because rogsoft supports three skins, a plugin has to ship separate ASP and CSS for each, with matching field placeholders so the same script can swap styling at install time. The README points at the aliddns plugin's `install.sh` as the worked example, at specific line ranges for detecting the required interface type and for applying the CSS swap, and at a `/* W3C rogcss */` marker comment in the matching ASP file that the swap keys on.

The last two rules are about preventing cross-platform installation. Offline packages must contain a `.valid` file whose contents include the string `hnd`, and every `install.sh` must detect the target firmware and platform before installing, because some older software centers on other platforms have no `.valid` check and would accept a package meant for this one.

Screenshots and skins, and one broken link

The README links images hosted on a user-images domain for each model row and for each plugin, which is why the tables render with pictures in the original. Those external links are outside the repository, so they are the part of this project most likely to have drifted from what the code actually does.

The homepage field points at asusgo.com and the download links point at `koolshare.cn` thread URLs, a Chinese forum. The README is written entirely in Chinese, and there is no translated version in the repository tree. For a project with 2,222 stars and 487 forks, that is a real accessibility limit: the tables are mostly model names, chipsets, and version strings, so they remain useful to an English reader, but the developer notes are not translatable at a glance.

There is also a straightforward typo in the second line of the README, which spells the organisation name with a doubled letter. It is the kind of thing that suggests the document is lightly maintained, which matches the absence of release tags. The last push was 2026-09-18, so the work itself continues; it is the packaging around it that has not been tidied.

Open issues number four, which for a repository of this size suggests either that users report elsewhere, most likely on the forum the download links point at, or that the plugin set has stabilised.

A licensing question the repository does not answer

This is the part worth raising before anyone builds on top of rogsoft. The repository's license field is empty and no license file appears in the tree. The README states obligations on plugin authors, such as installing into the correct platform and validating packages, but it does not state a license for the plugins themselves or for the software center code.

That is unusual for a project of this size and visibility. Many of the bundled plugins are ports or wrappers around upstream projects with their own licenses, and those upstream licenses still apply to the upstream code. What is unclear is the grant for the packaging, the ASP and CSS files, and the installation scripts that are original to this repository. Without a stated license, the default in most jurisdictions is that no permission is granted to copy, modify, or redistribute, which is a stricter position than a project with 2,222 stars is likely to intend.

The pragmatic reading is that this is a firmware modification community distribution, where plugins are installed onto a user's own router and the reference material is a forum rather than a package registry. If you want to fork a plugin, publish it elsewhere, or ship it in a product, that question needs an answer from the maintainers first. It is also the reason to treat the `.valid` and platform-detection rules as requirements to follow exactly rather than as obstacles to work around: those checks exist so that a package built for one platform cannot be silently installed on another.

Editorial conclusion

rogsoft is best understood as a compatibility contract rather than a software project. Nothing in it runs on a general purpose system, and the tables of supported models, chipsets, kernel versions, and skins are the actual documentation. A reader deciding whether to use it should check their exact model and variant against the tables, because four marketing names for one device are grouped in a footnote and the naming does not follow a pattern you can infer. A developer deciding whether to contribute has a sharper test, since the README states that plugins must be 32-bit, statically linked where possible, and carry a `.valid` file containing the string `hnd`. What the repository does not settle is licensing: no license file appears in the tree and the license field is empty, so there is no stated grant for reuse of these plugins, and no release tags exist to track versions. Both gaps are worth raising with the maintainers before building anything on top of it.

Frequently asked questions

Official sources

1. Issues
2. koolshare/rogsoft on GitHub
3. Project website
4. README