[GL-MT6000] Critical issues in v4.9 upgrade – configuration loss and security regressions

sefikail · June 27, 2026, 5:02am

After upgrading my GL‑MT6000 (Flint 2) to firmware v4.9, I encountered several critical regressions that significantly impact the device’s security and reliability.

Removal of “Block WAN for Unmanaged Devices” (drop_anonymous) The global default‑deny policy for unknown devices has been removed from Parental Control. This was the only reliable protection against randomized MAC addresses and an essential safeguard in case of Wi‑Fi credential exposure. I would appreciate clarification on why this feature was removed and whether it is planned to return.

No configuration migration The upgrade overwrote the entire configuration, including:

all Parental Control groups and schedules,
30+ MAC assignments,
custom Nginx reverse proxy settings,
language and localization files. All configuration had to be rebuilt manually from scratch.

LuCI Statistics broken LuCI now reports missing RRD/collectd components, indicating that required modules were removed or corrupted during the upgrade.

Summary I have been using this device since April 2026, and this is my second firmware upgrade. The extent of issues introduced in v4.9 is unexpected, especially given GL.iNet’s positioning as a provider of stable and reliable software. Compared to my experience with Turris devices, this update represents a noticeable step backward.

I would like to understand whether users are expected to manually reconstruct core network configurations after major updates. For most users, this is not a practical workflow.

I assume this behavior is not intended. However, if this level of disruption is to be expected in future releases, operating this device becomes an unsustainable time burden. I do not have the capacity to audit and repair my network after every update. I also hope that the declining usability of the device is not becoming the new standard for GL.iNet products.

If this reflects the long‑term direction of your software lifecycle, it makes further investment into GL.iNet hardware unjustifiable.

I request an official response from the GL.iNet development team.

will.qiu · June 30, 2026, 9:47am

Hi

We apologize for the inconvenience.

Regarding Parental Controls, we completely reworked the feature in v4.9.0. As a result, the old configuration cannot be migrated to the new system. We clearly noted this in the release notes.

Some features are also temporarily unavailable in the current implementation. We will discuss with the product team whether they can be reintroduced in future releases.

As for missing custom scripts or plugins, this is the expected behavior of OpenWrt-based firmware. By default, even if you select Keep Settings during a firmware upgrade, only the configuration files listed in the backup list will be preserved.

If you want your custom scripts or plugins to survive a firmware upgrade, you need to explicitly add them to the backup list:

Please note that we do not recommend preserving plugins across firmware upgrades. System components may change between firmware versions, and keeping plugins from an older firmware can cause compatibility issues, potentially leading to unexpected behavior or even preventing the router from operating correctly.

deejayreissue · July 1, 2026, 1:11am

This firmware update has been an absolute DISASTER for my IOT Thread mesh

IP addresses and devices constantly dropping off the mesh

I’ve had to revert to 4.8.3 to get everything stable again

sefikail · July 1, 2026, 1:12am

Thank you for your response. However, I must state that it is insufficient for a professional user.

Your argument that these regressions are “expected behavior of OpenWrt-based firmware” is not acceptable. As a customer, I purchased a complete commercial solution from GL.iNet, not a reference OpenWrt development board. I expect the manufacturer to guarantee the stability and functionality of the firmware provided, regardless of its underlying OS.

Misalignment of Responsibility
Regressions in core components such as collectd and LuCI Statistics are not “expected”—they are bugs. The fact that these features can be restored only through manual package reinstallation indicates a failure in your automated migration process (QA). I expect a “stable” firmware release to ensure functional continuity without requiring manual intervention from the end-user.
Unauthorized Removal of Product Functionality
Under Directive (EU) 2019/771, a product must retain the characteristics and features presented at the time of purchase. Removing the drop_anonymous toggle constitutes a unilateral change to the product’s parameters. While I understand you may not restore this toggle immediately, I must highlight that this decision reduces the value and security of the product, which is in conflict with the requirements for conformity.
Degradation of Product Value via Updates
Current trends in EU consumer protection legislation are increasingly focused on preventing manufacturers from degrading or disabling product functionality after purchase. A manufacturer should not systematically limit or remove previously available features through updates. I view this approach as problematic regarding the protection of customer investments.
Requirement for Stability
I operate my device in an environment that requires predictability. A “Move Fast and Break Things” approach is incompatible with the needs of professional users. I request clarification on your strategy for ensuring the stability of future updates to prevent similar regressions.
Required Actions
I formally request the following:

Explanation: Why is the functional continuity of core components (e.g., collectd) not guaranteed during the migration process?

Stance: What is the official rationale for removing the drop_anonymous UI toggle, and what alternative steps are you taking to ensure user security?

Strategy: How will you ensure that future “stable” firmware releases do not require manual repairs by the customer?

I firmly believe that GL.iNet aims to maintain the standards of a professional-grade product. I look forward to a substantive response that addresses these technical and legal shortcomings.

Best regards,
Aleš Krejčí

will.qiu · July 3, 2026, 4:34am

Hi Aleš,

Thank you for the detailed clarification. We understand your concern, especially regarding the previous Block WAN for Unmanaged Devices option, also referred to as drop_anonymous.

To clarify the change: in firmware v4.9, Parental Control was redesigned and moved to the new Flow Control architecture. The previous Parental Control implementation was the local beta version and was based on the older design. As part of the v4.9 redesign, the old Block WAN for Unmanaged Devices toggle was not carried over to the new UI.

We understand that this option was useful as a default-deny mechanism for unmanaged or unknown devices. At the moment, there is no exact one-to-one replacement for this specific Parental Control toggle in v4.9.

As a transition workaround, you may consider using Clients → Access Control → Allowlist. This is not the same Parental Control feature, but it can provide a similar whitelist-based security model at the client access-control level: only devices with specified MAC addresses are allowed to connect to the router. In some cases, this may be even stricter than the old behavior, because unmanaged devices are blocked from connecting to the router instead of only being blocked from WAN access.

Please note the difference between the two behaviors:

The old Block WAN for Unmanaged Devices option blocked Internet access for devices that were not included in the Parental Control list.
The Clients → Access Control → Allowlist feature only allows approved MAC addresses to connect to the router.

We agree that this is not a perfect one-to-one migration path, and we will discuss with the product team whether an equivalent default-blocking option should be restored or reintroduced in a future version of the new Parental Control system.

Regarding LuCI Statistics / collectd and other OpenWrt packages, these are third-party OpenWrt components rather than GL.iNet-maintained core features. We cannot guarantee that all third-party packages, their dependencies, or their runtime data will always be preserved across major firmware upgrades, especially when the underlying base system changes. We will continue improving the upgrade and migration process where possible, but third-party packages should be considered outside the guaranteed migration scope of the official firmware.

Best regards.

sefikail · July 3, 2026, 11:21am

Thank you for the reply. I must clarify why the Allowlist is not a viable replacement for drop_anonymous.

The Allowlist silently rejects unauthorized devices, removing visibility into connection attempts. No connection attempts appear in the UI, which reduces the ability to observe and analyze MAC probing or potential unauthorized access attempts. Unlike drop_anonymous, which allowed unknown devices to associate while being blocked from WAN access—and therefore made them visible in the client list—the Allowlist approach removes this monitoring capability entirely.

Security is not only about preventing access, but also about visibility, monitoring, and incident awareness. While this may be a stricter access-control model, it represents a significant loss of security transparency. If my assessment is incorrect, please explain how unauthorized connection attempts can be monitored in this architecture without manual SSH access.

The drop_anonymous functionality was a key factor in my decision to purchase this device, as it was part of the security monitoring and visibility features available at the time of purchase. Its removal represents a functional degradation of the product’s originally available feature set.

Beyond the technical issue, I am dissatisfied with how this upgrade was handled. The lack of a migration path for a redesigned core feature such as Parental Control, and the explanation of regressions as “third-party” or “outside scope”, is not a sufficient justification from a product perspective. These are GL.iNet-branded features, and responsibility for their continuity lies with your product design and release process.

I need a straight answer: Is this “wipe and rebuild” approach the new official standard for major firmware updates? Should users expect that future major updates will require factory resets and manual reconfiguration? If this is the new normal, the product no longer aligns with the requirements of a professional-grade environment.

I hope this feedback is taken seriously, as it directly affects my confidence in future investment in your hardware and whether I can continue recommending your ecosystem to others.

manuelrhdotcl · July 4, 2026, 9:55am

Hi all,

I agree with this issue, for me and my devices was critical.

I would think that these kinds of adjustments were part of a mayor release (Considering semantic versioning).

kaserei · July 6, 2026, 10:33pm

I have mentioned in a feedback note that the absence of “drop_anonymous” is an unfortunate regression for other reasons.

I use(d) a parental control group to block clients that submit egregious telemetry and process unwanted upgrades without supervision (qnap/tapo/amazon/etc.. devices for example). I simply can no longer identify these devices on the network before they connect and complete their nefarious deeds unless I unplug the whole network before plugging them in since 4.9.x.

I haven’t identified any other issues but network performance has been bad in multiplayer peer to peer games since the upgrade. I have not investigated yet, and will likely downgrade before I do as my kids now know how to bypass the mac filter because of the missing drop_anonymous check.

Watching this thread for updates

sefikail · July 11, 2026, 2:38pm

After persistent attempts to resolve core issues in good faith, it is clear that GL.iNet has no intention of addressing the regressions introduced in v4.9. The pattern of political replies, deflection, and silence speaks for itself.

The reality of the current firmware policy:

Destructive Updates: “Keep settings” is non‑functional; major updates force a manual “wipe and rebuild”.
Security Regressions: Removing drop_anonymous without replacement creates unnecessary security blind spots.
Lack of Accountability: Core GL.iNet‑branded features are routinely dismissed as “third‑party” or “out of scope”.

This is not a professional product lifecycle — it is a “Linux‑on‑hardware” hobbyist project presented as commercial hardware.

The result is a dangerous security paradox: users must choose between running outdated, vulnerable firmware or “upgrading” to a version that actively breaks network security. This strategy of planned functional degradation is professionally negligent and fundamentally unethical.

I am done investing in this ecosystem. I will be sharing my findings across broader security and hardware communities to warn other professionals about the risks of committing to GL.iNet firmware.

Rivo · July 11, 2026, 8:47pm

A detailed doc on the migration path should be provided at least, with detailed description of potential lost features before upgrade.

I was used to allow extra time for some clients as needs arise. The current Parental control interface doesn't allow such exceptions to be easily toggled, apart from manually disabling the whole rule … and hopefully not forgetting to enabling it back again some time later.

will.qiu · July 14, 2026, 7:51am

Hi Aleš,

We are sorry that firmware v4.9 did not meet your expectations. However, we would like to clarify several points, as some of the conclusions in your latest post do not accurately reflect how the upgrade process works or what we previously stated.

First, Keep Settings remains functional. It is intended to preserve supported configuration files during an upgrade; it does not mean that the complete writable filesystem, every user-installed package, package runtime data, or every custom file will be carried over unchanged.

For GL.iNet-maintained features with known migration limitations, these exceptions are documented in the release notes. In particular, the v4.9 release notes explicitly stated that Parental Control had been comprehensively redesigned, that its existing configuration could not be preserved, and that users would need to configure it again after upgrading.

Therefore, it is not accurate to conclude that major firmware updates generally require a factory reset or a complete manual “wipe and rebuild.” The Parental Control configuration was a specifically documented migration exception caused by the redesign of that feature.

Second, regarding drop_anonymous, we have not dismissed Parental Control as a third-party feature. It is a GL.iNet feature, and we addressed its redesign separately.

The release notes clearly informed users that the previous Parental Control configuration would not remain active after the upgrade and that the feature needed to be reviewed and reconfigured. Users should therefore check their security-related settings after completing the upgrade rather than assume that policies from the previous implementation have been silently carried over.

We understand that you consider the previous Block WAN for Unmanaged Devices behavior important, and we have already acknowledged that the current Allowlist mechanism is not an exact one-to-one replacement. We will continue discussing with the product team whether equivalent behavior should be reintroduced. However, describing the documented redesign as an undisclosed security blind spot or as firmware that “actively breaks network security” does not accurately represent the upgrade notice or the available access-control mechanisms.

Finally, collectd, LuCI Statistics, custom Nginx configurations, and other manually installed OpenWrt packages or plugins are third-party or user-customized components. They are not part of the GL.iNet-maintained firmware feature set, and we cannot guarantee their compatibility, preservation, or continued operation across major firmware upgrades.

This does not mean that GL.iNet-branded features are being categorized as third-party. It means that packages and customizations installed outside the official GL.iNet firmware scope are not covered by our firmware migration and compatibility commitments.

We respect that different users have different requirements for their network environments. If firmware v4.9 or the available transition options cannot meet your requirements, please contact support@gl-inet.com so that our support team can review your case and discuss the available options with you directly.

Best regards.

will.qiu · July 14, 2026, 7:54am

Hi Rivo,

Thank you for your suggestion.

We agree that users should be informed in advance about important configuration changes and migration limitations.

For this upgrade, the Release Notes did specifically explain that Parental Control had been comprehensively redesigned, that the existing Parental Control configuration could not be preserved, and that users would need to configure the feature again after upgrading:

That said, we appreciate your feedback that the migration impact and the differences between the old and new implementations could have been documented in greater detail. We will share this suggestion with the relevant team so that future release notes and migration guidance can be made clearer.

Thank you again for your feedback.

sefikail · July 14, 2026, 12:08pm

Your response avoids the core issues that were raised. Instead of addressing the actual technical regressions, responsibility is shifted to release‑note disclaimers, OpenWrt limitations, or private support channels.

This is not how a professional product is maintained. Here is what remains unanswered:

Configuration Loss: Pointing to a release-note disclaimer does not change the real user experience. Most customers expect a commercial router to preserve their configuration after a firmware update. Requiring users to manually rebuild their entire setup is not an acceptable workflow. When an update damages configuration or system components to the point where an average user cannot recover the device on their own, it creates a security risk that should never arise from a firmware update.
Broken System Packages (LuCI, collectd): These packages are part of your pre-installed firmware. If an update causes them to stop functioning, customers understandably see this as a product-quality issue. The dependency failures clearly indicate major gaps in integration testing.
Removed Security Feature: Removing Block WAN for Unmanaged Devices and presenting it as a “redesign” ignores the fact that there is no full replacement in the current version. This feature was one of the key reasons I purchased the device. After the update, the product provides lower security visibility than it did at the time of purchase.
Network Instability: Reports from other users regarding IoT mesh instability and degraded peer-to-peer performance remain unaddressed.
Recurring Update Issues: Your official forum is filled with reports of configuration loss, package incompatibilities, and Wi-Fi regressions. This does not look like an isolated incident — it looks like a pattern.

The practical result is a product that offers fewer features after the update than it did at the time of purchase.

I purchased this router brand-new just three months ago (April 7, 2026). I expected a stable commercial device, not a project I would have to repair after every update. The time I spent fixing the consequences of this upgrade is time no customer should have to invest — and certainly not repeatedly.

A simple analogy: you buy a new car, and three months later a software update removes the alarm system and parts of the dashboard functionality. Regardless of the reason, you are left with a product that does less than it did when you bought it — with no way to restore the original state. The European Union is already preparing and implementing regulations that classify such post‑purchase degradation of functionality as an unfair commercial practice subject to significant penalties.

I am not interested in moving this discussion into private email. Public issues deserve public answers.

As a software engineer, I understand that bugs happen. But this is not about isolated bugs — it is a recurring pattern that points to shortcomings in release management and quality assurance, not to individual developer mistakes. The developers are not the problem here. The issue lies in leadership decisions, missing processes, and the lack of safeguards that should prevent regressions from reaching end users.

If this pattern continues, I will document my experience publicly, including on Reddit and other technical communities. I apologize if this message sounds blunt, but the level of amateurism demonstrated by this update is in stark contrast to the overwhelmingly positive reputation your products have online. I genuinely did not expect a device with such strong reviews to end up in this state after a single firmware update.

sefikail · July 14, 2026, 12:30pm

Short additional comment:

Just to be clear — this isn’t a developer mistake. What we’re seeing here is a failure of architecture and leadership. A proper Software Architect would never allow a firmware release that wipes configs, breaks core packages, removes security features, and destabilizes networking. These aren’t coding bugs. They’re the direct result of how the company’s owners and leadership have chosen to set their standards — and those standards clearly aren’t high enough to protect customers.

xize11 · July 14, 2026, 12:37pm

Problem with preserving files when doing a upgrade your router is becoming extremely vulnerable to space at that exact moment, also the problem is... If people have mounted their /overlay wrongly they will boot OpenWrt with a broken toolchain of kernel packages, permanent mounting is recorded in the fstab file, but the upgrade process is not aware of the extra overlay from fstab so the flash got written only to the non overlayed part in /overlay, you really don't want to boot and get this mount back.

OpenWrt is designed with the idea it will wipe everything, if there was no space left it would break the router.

It is a intended safe guard, however writing migration code for existing configuration when files are kept is kind of dangerous imo it must be tested carefully because it is not a aware process, the chances will be low on gl routers about space that it is a issue, but on OpenWrt some routers only have 16 or 32mb flash.

But I do agree that this need to be communicated better, and if possible advise GL-iNet to keep current config conventions as much as possible, constant changing this will cause the more dangerous part.

sefikail · July 14, 2026, 1:26pm

Your argument makes sense from the perspective of a hobbyist who enjoys tinkering with the system, but not from the perspective of a customer who bought a commercial router. I purchased this device to serve as a stable foundation for Home Assistant, not as a platform where I have to troubleshoot overlays, fstab, or the underlying philosophy of OpenWrt’s security mechanisms. These internal details are irrelevant to me — I expect updates to be safe and the device to remain fully functional afterward.

I don’t want to disable updates, I don’t want to write custom integrity scripts, and I certainly don’t want to perform a system audit after every upgrade. I want a device I can set and forget — while still receiving safe, non-destructive updates. This is 2026, not 2010; it is perfectly reasonable to expect a commercial product to function without the user having to be a professional systems administrator.

I’m not even asking for new features. I appreciate them, but at the time of purchase the router already had almost everything I needed, and anything else I can add through the community. I’m not interested in “upgrades” if they come at the cost of original functionality. I expect stability, not experiments.

If the firmware is designed in such a way that an update can cause configuration loss or break core components, then the problem lies in the architecture itself. A commercial product must guarantee stability and predictability — it should not force the user to become the administrator of their own router.

groentjuh · July 14, 2026, 1:28pm

OpenWRT's upgrade behaviour is make a backup of the config, wipe all and rebuild filesystems from update package and last restore the backup of the config. If you did anything anywhere that's not in the backup, it will be gone after an update.

The trouble to keep installed packages is that these may have dependencies that may have been changed or upgraded. So in that case you would still run into situation in which after updating something may not work due to those dependencies having changed.

The best GL-inet could do, is maintaining/generation a list with packages installed previously and try to reïnstall those after having upgraded. In those case you may still have the possibility things may have changed or packages being no longer available or having been renamed etc etc... And that also may not retain any further changed that were done elsewhere (Nginx config for example!)

Lets be really honest: GL-inet allows us to do awesome things with the hardware they make. They could also just lock down EVERYTHING (like many manufactures do) except what their own GL-inet GUI allows you to do. That way they can more guarantee there will be no issues, but that way you also cannot do those same modifications you did to your device... Is that what you are really wishing for? Cause that's the ONLY way updates could be very effortless!

xize11 · July 14, 2026, 1:30pm

It depends also what you want to preserve there is a file in /etc/sysupgrade.conf where you can whitelist directories and files this will then not be wiped anymore when the checkbox keep files is checked .

I think if I was in this position I probably ended with adding a usb mount and use docker to point to the usb as location for the socket and its containers, to me docker is a really immutable way of creating containers really fast and updating them without the dependency nightmare that some packages miss.

I think reinstalling packages after upgrade won't hurt, its something how OpenWrt does it with package attended-sysupgrade or owut.

sefikail · July 14, 2026, 2:21pm

@xize11 @groentjuh It is completely detached from the reality of a commercial router to defend destructive update patterns as “protection” or “freedom.” This is not freedom; this is offloading engineering burden onto customers. And crucially — it is technically solvable. Anyone claiming otherwise is either a junior developer who doesn’t understand the problem, or knowingly lying.

Arguments like “OpenWrt works this way,” “just whitelist files,” “move it to USB,” “use Docker” only prove you’re looking at the problem through the lens of a hobbyist. This is a commercial product, not a DIY project.

A commercial router cannot expect customers to manually repair the system after every update. This is not a philosophy — it is a failure of the vendor layer.

Example: in Germany, a large-scale open‑source deployment ended up more expensive than proprietary solutions, simply because long‑term maintenance, stability and operational costs were ignored. This perfectly illustrates how out of touch both gentlemen in this discussion are — the commercial world is not a hobby playground.
GL.iNet can afford to grab OpenWrt, skip migrations, skip stabilization layers, skip “set‑and‑forget” reliability, and ship it as a finished product because it’s cheap for them. They have the nerve to do it — but the user pays the price.
And in any real commercial deployment, this approach simply does not survive.

When a vendor ignores migrations, stabilization mechanisms and responsibility for the update process, the result is always the same: higher cost, instability, and eventual abandonment of the product.

groentjuh · July 14, 2026, 2:36pm

I see you are looking for a locked down, walled garden, in which a manufacturer can INDEED support all migrations. If that's what you are looking for, go to such a eco-system and stay far away from anything based on OpenWRT...

Is better possible? Yes, as I mentioned they could do a better effort to restore packages previously installed. Will that solve everything as you apparently believe that should just work: No.