wukongdaily/gl-inet-onescript for GL-iNet routers

The exact router and firmware gap addressed by the scripts

wukongdaily/gl-inet-onescript addresses a specific difference between the software shipped by GL.iNet and the application experience associated with iStoreOS. The README states that the project gives supported ARM64 GL.iNet routers the latest iStoreOS style without replacing the firmware with a newly flashed image. This is useful for an administrator who values the interface and application workflow but does not want to move the router to a separate OpenWrt image.

The supported list is broad in model names but narrow in actual deployment conditions. It covers GL.iNet BE-6500, BE-9300, BE-3600, MT-5000, MT-3600BE, Mudi 7 or GL-E5800, MT-2500A, MT-3000, and MT-6000 devices. The documentation also separates firmware generations. Factory MT3000 systems are described as running Luci 21 with kernel 5.4, while newer op24 and op25 packages use Luci 24.10.4 with kernel 6.6 and Luci 25.12.5 with kernel 6.12 respectively. BE-family support is further associated with Luci 23 or Luci 21.

This is not a general-purpose OpenWrt distribution. The repository layout reinforces that point. It contains separate scripts and model directories for MT-2500A, MT-3000, and MT-6000, alongside other top-level Shell files. Based on that structure, compatibility is tied to a combination of hardware model, factory firmware, Luci generation, and kernel generation.

The likely user is therefore a router administrator who already has SSH access and accepts the consequences of installing additional software. The README does not promise support for every GL.iNet router, does not document arbitrary ARM64 compatibility, and does not provide a complete matrix for every firmware build. It also does not explain exactly which system components remain untouched. That makes an inventory of the current installation more relevant than the product's broad model list.

How main.sh branches for GL.iNet hardware

The documented installation starts with a main script hosted under the `cafe.cpolar.cn` endpoint. The README says that this entry point automatically detects the router model. It then directs the installation toward support branches for the listed GL.iNet models and firmware families.

The execution model is remote Shell evaluation. The command downloads the complete script body with curl and passes that body to `sh` in the same operation. According to the README, model detection is automatic only for this main path. Individual model scripts are also provided when a user wants to bypass automatic selection or needs a script associated with a particular firmware generation.

That design keeps the user-facing command small, but it also concentrates trust in the remote endpoint and the current contents of its `main` branch. The README does not document a checksum, release verification step, or method for reviewing the fetched script before execution. Nor does it describe what happens when detection cannot match the installed firmware. An administrator should not assume that a model name alone resolves the ambiguity created by different kernel and Luci versions.

The model-specific scripts expose the same general mechanism. For example, the MT3600BE and Mudi 7 entries both use `mt3600.sh`, while MT3000 and MT6000 have separate op24 and op25 scripts. BE6500, BE3600, MT5000, and the factory-system MT3000 path also have named scripts. These dedicated paths are useful when the administrator knows the supported hardware and firmware combination.

The repository includes a second option called glibox, based on dufs, for serving scripts inside a local network. The README documents both x86-64 and arm64 for that server. This addresses a practical failure case in which the router cannot download the hosted script because of network access, although it does not make the remote command suitable for every deployment model.

First SSH use with automatic model detection

The shortest documented first use requires SSH access to the router. The main script is fetched and executed immediately, with no repository checkout or package installation step shown in the README. The expected result is that the script detects the model and follows the matching GL.iNet installation path.

Run the automatic entry point over SSH:

sh -c "$(curl -fsSL https://cafe.cpolar.cn/wkdaily/gl/raw/branch/main/main.sh)"

The README states that automatic detection supports the listed BE, MT, and Mudi models across Luci 21, Luci 23, op24, and op25 contexts. It also documents a quick-execution parameter for locally invoked scripts, such as the following:

sh be3600.sh -q

That second command applies to `be3600.sh`, not automatically to the remote `main.sh` invocation. The README does not describe the output format or the final success message, so it would be wrong to promise a particular banner or status line. The relevant observable result is whether the script completes and whether the router presents the expected Luci interface.

For firmware versions identified as 4.7.0 or later, the README directs administrators to access Luci through port 8080:

http://192.168.8.1:8080

The example is not fenced with a programming language because it is a router address rather than a command or code sample. The separate troubleshooting discussion linked by the README covers access refused messages on port 8080. That indicates that interface reachability can be an issue separate from whether model-specific execution begins.

Running a known MT3000 or MT6000 firmware path

Users who already know their hardware and firmware can select a model-specific script instead of relying on automatic detection. For an MT3000 running the factory Wi-Fi 6 system with Luci 21 and kernel 5.4, the README gives this command:

sh -c "$(curl -fsSL https://cafe.cpolar.cn/wkdaily/gl/raw/branch/main/gl-inet.sh)"

The op24 path targets the original op24 firmware for MT3000 and MT6000. The README associates that firmware with Wi-Fi 6, Luci 24.10.4, and kernel 6.6:

sh -c "$(curl -fsSL https://cafe.cpolar.cn/wkdaily/gl/raw/branch/main/gl-inet-op24.sh)"

For the op25 path, the documented association is Wi-Fi 6, Luci 25.12.5, and kernel 6.12. It also applies to MT3000 and MT6000:

sh -c "$(curl -fsSL https://cafe.cpolar.cn/wkdaily/gl/raw/branch/main/gl-inet-op25.sh)"

These commands should be treated as mutually exclusive deployment choices based on the installed firmware, not as three commands to run in sequence. The README does not document a script-level dry-run flag, dependency listing, configuration prompt, or rollback command for these paths. It also does not state whether a failed run can leave partially installed packages or modified files. That absence prevents a firm claim that the operation is atomic.

The direct commands also depend on remote connectivity during execution. An administrator who cannot reach the documented endpoint should inspect that condition before diagnosing the router's application stack.

BE, MT3600BE, MT5000, and Mudi 7 routes

The repository provides named scripts for newer device families. BE6500 is described as Wi-Fi 7 and as sharing the BE9300 path. Its command is:

sh -c "$(curl -fsSL https://cafe.cpolar.cn/wkdaily/gl/raw/branch/main/be6500.sh)"

BE3600 is also described as Wi-Fi 7 and has its own script:

sh -c "$(curl -fsSL https://cafe.cpolar.cn/wkdaily/gl/raw/branch/main/be3600.sh)"

MT3600BE receives a dedicated Wi-Fi 7 script:

sh -c "$(curl -fsSL https://cafe.cpolar.cn/wkdaily/gl/raw/branch/main/mt3600.sh)"

The README states that Mudi 7, identified there as GL-E5800 and described as a 5G NR tri-band Wi-Fi 7 travel router, uses the same `mt3600.sh` path. Sharing a script is not evidence that every configuration detail is identical to MT3600BE, but it is the documented selection rule for Mudi 7.

MT5000 has a separate route and is described as having three 2.5G wired connections:

sh -c "$(curl -fsSL https://cafe.cpolar.cn/wkdaily/gl/raw/branch/main/mt5000.sh)"

These entries are useful when automatic detection is undesirable or when an administrator has already identified the intended branch. They also expose a practical weakness: the README's descriptions do not provide detailed installation prerequisites for each model. The model name and Wi-Fi generation are documented, but hardware revision, installed image, and required Luci version are not presented as a complete per-device checklist.

The repository refers to the iStore project as a design reference. Consequently, iStoreOS itself is the relevant alternative approach, not merely another router skin with identical deployment mechanics.

Local glibox delivery when the router cannot fetch scripts

The README documents glibox as a local file server for this project's scripts. It is based on dufs and supports x86-64 and arm64. The documented Docker deployment publishes container port 15050 on host port 15050:

docker run -d \
  --restart unless-stopped \
  --name glibox \
  -p 15050:15050 \
  wukongdaily/glibox

This option is intended for routers that cannot download the scripts because of network problems. The administrator first runs the container on a reachable machine, then connects by SSH to the router and enters the glibox LAN address.

For MT3000, MT2500, or MT6000, the README gives this command:

read -p "请输入glibox局域网 IP: " ip && wget -O /tmp/gl.sh http://$ip:15050/glinet/gl-inet.sh && sh /tmp/gl.sh $ip

For BE3600, it uses the corresponding script path and passes the address as an argument:

read -p "请输入glibox局域网 IP: " ip && wget -O /tmp/gl.sh http://$ip:15050/glinet/be3600.sh && sh /tmp/gl.sh $ip

Unlike the remote `curl` command, these examples download into `/tmp/gl.sh` before invoking it. That makes the fetched file an explicit local step, although the README still does not say whether the script should be inspected before execution. Passing `$ip` also indicates that these local variants have a model-specific expectation about the server address. The repository does not document local commands for every supported model, so the MT3000, MT2500, MT6000, and BE3600 examples should not be generalized to unsupported routes.

The glibox image is published under `wukongdaily/glibox`, while this article evaluates `wukongdaily/gl-inet-onescript`. The README links Docker Hub tags for the image, but it does not document an image version alongside the repository release.

Compatibility limits, license, and maintenance

The largest limitation is explicit model and firmware coupling. The README documents separate paths for factory systems, op24, op25, and several Wi-Fi 7 models. An administrator with an unlisted GL.iNet product cannot conclude that the generic ARM64 wording makes the script safe. Likewise, the repository does not document behavior for an unknown model, an unsupported kernel, or a firmware revision that differs from the examples.

The operational limitation is equally concrete. The main command executes remote content directly, while the model-specific examples do the same through `curl`. A network failure, unavailable endpoint, incorrect branch, or unexpected local environment can interrupt the process. The README links an SSH guide for duplicate `known_hosts` entries and a discussion about port 8080 refusal, which confirms that connection setup and interface access have separate failure modes. It does not document a rollback procedure, transaction log, or automatic restoration after a partial failure.

The repository is licensed under GPL-3.0. That identifies the license associated with the project, but it does not by itself describe licensing for scripts fetched from the remote host, the referenced iStore project, or third-party packages installed after execution. The README refers to istore as a reference project and links iStoreOS, yet it does not enumerate every dependency or their licenses. An organization needs to inspect those components separately rather than treating the top-level license as a complete dependency manifest.

The repository is not archived, and the last push was on 2026-08-08. Recent releases include an MT3600BE entry for OpenWrt 25.12.5 on 2026-08-08, a factory OpenWrt 25 archive for MT3000 and MT6000 on 2026-07-22, and an MT3000 one-script log release on 2025-12-12. These records show device-specific release work, but the README does not state a general upgrade policy or a stable-release channel for the main script.

Editorial conclusion

Adopt this project if you own one of its listed ARM64 GL-iNet routers, run a supported Luci or OpenWrt version, and specifically want an iStoreOS-style interface without reflashing. Do not adopt it if you need a fully documented OpenWrt image lifecycle, a reversible package-level deployment, or guaranteed support for an unlisted router. Verify the model, current firmware, Luci version, and kernel stated in the README before running anything, because the script modifies installed router software and immediately executes content fetched from a remote URL.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. wukongdaily/gl-inet-onescript on GitHub