GL.iNet Minimal Firmware: Stripping Bloat, the QSDK Wall, and Where the Flint 3 Really Stands
The bundled app problem
GL.iNet routers ship with a set of services baked in: GoodCloud for remote device management, Astrowarp for their mesh and VPN platform, Bark for parental controls, and a DPI engine. For most buyers those features are irrelevant. For privacy-focused users, they’re actively unwanted.
Some of this can be dialed back in the admin panel. GoodCloud has a toggle under Applications → GoodCloud — flip it off and it stops communicating with GL.iNet’s servers. Disabled, though, is not the same as gone. The IPK packages, associated processes, and attack surface all remain on the device. For anyone who cares what their router is actually running, that distinction matters.
Why building your own GL.iNet image is hard
GL.iNet maintains a public imagebuilder on GitHub. On older hardware — MT, AR, and some AX-series devices — it works: you specify packages to add or subtract and it produces a flashable image without compiling everything from source. Genuinely useful, and worth knowing about if you’re on that generation of hardware.
The wall you hit with newer Qualcomm-based devices like the Flint 3 (GL-BE9300, IPQ5332) is the QSDK. Qualcomm’s proprietary SDK ships as pre-compiled blobs bound to its own toolchain. GL.iNet doesn’t control what Qualcomm exposes through that SDK, and several proprietary packages — Astrowarp and Bark among them — aren’t accessible through the imagebuilder at all. You cannot subtract what you never had control over.
There’s also a business-model dimension. GoodCloud and Astrowarp are revenue-linked services. A firmware builder that cleanly lets users opt out would be useful to the enthusiast segment, but it would also hand customers a tool to reduce adoption of the features funding GL.iNet’s ongoing development. That tension explains why this request keeps appearing on the GL.iNet forum and keeps not shipping.
Mainline OpenWrt on the Flint 3: the current state
The common assumption — including in the original forum post — is that the Flint 3 will probably never run vanilla OpenWrt because of the QSDK. That was reasonable a year ago. It’s less accurate now.
A community port targeting the qualcommbe/ipq53xx target on kernel 6.12 has made real progress. As of mid-2026, the following all work:
- LAN through the RTL8372N switch with DSA, at near line-rate throughput
- WAN at 2.5 Gbps via the RTL8221B PHY
- Both QCN6274 radios — 5 GHz and 6 GHz — including client association, SAE, and DHCP
- eMMC persistence with f2fs overlay and sysupgrade support
- Tagged and untagged VLANs
What isn’t working: the 2.4 GHz on-SoC radio. It hits a TrustZone authentication failure at the final bring-up step — something GL.iNet and Qualcomm are apparently investigating together. Cold-boot from eMMC is also unreliable (around 50% success), which makes TFTP the safer flashing path for now. There’s also some 6 GHz packet loss on certain channels.
One developer has been running this as a live home AP with dual-VLAN trunking and roaming support. Not ready for every deployment, but functional for someone comfortable with the rough edges.
What you can actually do today
Older MT, AR, and AX-series hardware
The GL.iNet imagebuilder is your clearest path. Prefix package names with a minus sign to exclude them from the build output. You won’t strip every proprietary component — some GL.iNet packages aren’t exposed at all — but you can slim the image meaningfully while keeping whatever parts of the GL UI you actually use. On most of this older hardware, flashing upstream OpenWrt directly via sysupgrade is also a straightforward option.
Flint 3 and newer Qualcomm devices
Right now your options are: disable what you can through the admin panel, follow the mainline port and flash it when it’s stable enough for your needs, or move to hardware without a QSDK wall. The GL-MT6000 (Flint 2) runs on a MediaTek chipset and has solid mainline OpenWrt support — no QSDK complications. If a fully open router matters more than Wi-Fi 7, that’s the practical answer today.
If you do want to try the Flint 3 community port now, go in expecting TFTP flashing, no 2.4 GHz band, and occasional cold-boot failures. For a secondary AP or a lab device, that’s a workable trade-off.
What a firmware builder would actually require
The firmware builder request is technically straightforward — the imagebuilder already does package selection from the command line, and a web front-end on top of it isn’t a novel engineering problem. The real barrier is that GL.iNet would need to expose the build toolchain for QSDK devices publicly, which involves Qualcomm’s licensing terms, and then decide to support users who want to remove the services that generate recurring revenue. Both of those are business decisions, not engineering ones. Worth requesting clearly and loudly on the forum — that kind of consistent signal does eventually move vendor roadmaps — but don’t expect it on a short timeline.
Sources
