I have discovered a very strange bug after upgrading my GL-MT6000 Flint2 firmware to 4.9.
First, before the upgrade I got a notice that my Parental Control settings cannot be migrated. Not great, and hardly understandable (new parental control can easily be mapped 1:1), but ok. Upgrade went fine, and I have recreated rules for limiting online time on 1 pc and 1 phone in the LAN, from scratch - just "Bedtime", no filtering ("No content filtering" in the GUI).
But soon after that, my two sons had independently noticed that League of Legends is not working properly, they could not join the game. After several experiments with DNS that was our first suspect I turned off new Parental Control and the game started working.
And now the best part: one of the affected computers is listed in Parental Control (although there still should not be any game or other content filter applied!), but the other is not. So it seems that just enabling Parental Control blocks some of the traffic on the whole LAN.
Please let me know if there is any better solution than to downgrade the firmware to 4.8.4 and restore the config from save and wait for next, hopefully fixed version.
1 Like
Hi
Sorry for the delayed reply.
Could you please help us check the following?
-
When the issue occurs, SSH into the router and run the following commands to check the status of Parental Controls, then share the results with us:
cat /proc/parental-control/group
cat /proc/parental-control/rule
-
Could you also please follow the guide and share your device with us via GoodCloud so that we can investigate it remotely?
Technical Support via GoodCloud - GL.iNet Router Docs 4
Kindly send us the router's MAC address and password via private message so that we can access the device.
Here are the results for the files you wanted:
root@GL-MT6000:~# cat /proc/parental-control/rule
ID Action Refer_count APPs
accept 1 0 [ ]
Black List:
ID Name Proto Sport Dport Host_url Request_url DataDictionary
=======================================================
drop 0 0 [ ]
Black List:
ID Name Proto Sport Dport Host_url Request_url DataDictionary
=======================================================
root@GL-MT6000:~# cat /proc/parental-control/group
ID Rule_ID MACs
group7307602 NULL [ 0e:e5:e5:9c:40:bb ]
group2986748 NULL [ 10:ff:e0:a9:00:86 ]
As I am now on vacation, I will not perform more experiments till next week.
Thank you for the update.
At the moment, this information doesn't appear to point to the root cause of the issue.
It may be need to wait until you have some time next week, and then we can take a closer look by accessing the router remotely via GoodCloud.
The support staff is asking you to check /proc/parental-control/, but that only shows the current broken runtime state. It doesn't tell them why it's broken.
If you check your configuration directory: ls /etc/config/parental_control* you will likely see both parental_control and parental_control_v2 coexisting. The issue is that the developers failed to implement a migration path for the config files during the v4.9 upgrade.
They seem to be ignoring the root cause—that the old config wasn't migrated to the new schema—and are instead wasting time on remote debugging sessions. I've documented the scale of these upgrade failures in my own thread, where the damage went far beyond just one broken feature: https://forum.gl-inet.com/t/gl-mt6000-critical-issues-in-v4-9-upgrade-configuration-loss-and-security-regressions/69578.
Unless they address the fact that they didn't perform a proper v2 transition for these configuration files, they won't find the 'root cause' because they aren't looking at the right place
I understand they did not even try to implement migration (even though all old rules seem to be convertible to new ones). Not sure why, not great for sure.
Blocking some of the traffic regardless of time limits (I see impact on LoL server connections, but maybe there is more?) seem to be possible only in new mechanism, the one that I configured from scratch, and in which I specifically set content filtering to be off for all of the rules (3 in total). And of course fact that machines not selected for parental control are affected is the bigest problem here - what other filtering / packet inspection is happening without my knowledge? I do see two parent control config files in /etc/config, but it would be quite evil mess if this is causing the observed issue.
PS I have also checked that disabling all 3 rules still does not fix the problem - I need to disable the whole parental-control feature. This also suggests that the problem is not within config rules themselves, but rather somewhere around predefined configs for various "content groups" to be filtered.
The ghost config files are definitely the issue. I faced the same disaster and had to manually recreate all my rules from scratch via the web interface.
Honestly, it is disappointing to see such a lack of a migration path in the new firmware. Expecting users to manually reconfigure everything after an upgrade feels like an oversight that shouldn't happen with a product like this. If the system is still filtering unselected devices, it confirms that the upgrade process left the router in an inconsistent state.
Hi
As you know, Parental Controls were completely reworked in the new firmware, and some configurations and behaviors have changed.
For that reason, we intentionally do not migrate the old configuration. Instead, we prefer to clearly inform users that the previous settings cannot be migrated and recommend creating the rules again and verifying that the new behavior matches their expectations. This helps avoid situations where settings are silently migrated but behave differently due to the redesigned implementation.
We can confirm that the legacy configuration file, /etc/config/parental_control, does not affect the new implementation. The new Parental Controls feature is managed entirely through /etc/config/parental_control_v2.
If you'd like, you can also remove or move the old configuration file to verify this:
# Remove it
rm /etc/config/parental_control
# Or move it elsewhere as a backup
mv /etc/config/parental_control /root/parental_control
As mentioned previously, we may need to investigate the issue further through GoodCloud to determine the root cause.
As we managed to resolve the issue, I will add summary here for other users.
The problem is connected with disruption of long-lived UDP connections caused by bug in 4.9 Parental Control content filtering implementation. The root cause has been found, and I understand the fix will be available in future version of the firmware.
But there is also a workaround available that helped in my case. It is enough to add at least one manually blocked domain to the parental control rule (can be bogus, like one I used: "parental-test.invalid" as in the attached picture), so the rule has at least one domain in content filter section.
1 Like
