I just thought I'd share my experience here with everyone regarding upgrading to firmware 4.9.1 on a Flint 2 (GL-MT6000) using custom VLANs.

Starting with the one-liner punchline: It's been very good after a pretty simple (but necessary) tweak.

If you don't want to read additional context and details and are only interested in the "tweak", you can likely just scroll to the "What I did" section as long as you know that this applies to you and you know what you're doing.

Details

First, a few things worth emphasizing for context:

• My general philosophy is never to upgrade to the latest firmware right away unless the firmware addresses something critical (e.g., a security vulnerability) or stands to help me do something I want to do. And to be clear, that's for anything (not just GL.iNet), and I apply this to both my personal use and for any hardware I manage for someone else. This means I often hang back a release (or more). Why? Well, the reality is that no matter how much a piece of firmware gets tested prior to release, there's often still a lot to be learned by "in the wild" testing after the firmware is formally released and many more people start testing it beyond any beta testing. I often think of the initial period after general availability being an extended beta testing period.
• Many in the GL.iNet community expressed a strong desire for firmware updates to be more heavily tested prior to release. And I think GL.iNet did that with the 4.9.0 firmware. Was it perfect? Nope. Did it still have bugs? Yep. But I don't think anyone can deny that they aimed to test 4.9.0 much more extensively than with some previous releases of late. That deserves recognition and appreciation. (And no, I'm not some sycophant or shadow employee. I've pointed out bugs and offered constructive criticism myself in the GL.iNet forum and Reddit group.)
• I'm firmly in the camp of being entirely fine with (more directly, I am strongly in favor of) a slowed pace of firmware releases that are as rock-solid as they can possibly be prior to general availability. I'm also in the same camp when it comes to the pace with which GL.iNet seems to be developing and releasing new hardware, simply because each new hardware release comes with a commensurate maintenance burden; but GL.iNet is a company, companies need to make money, and I imagine there's a pressure to continue releasing new hardware.
• The sheer number of permutations that exist with a highly-customizable setup like what is offered in GL.iNet devices vastly increases the problem space for testing. I often feel like this is underappreciated. This in no way undermines the need for extensive, dedicated testing or anything else I've already said above. But it does offer some important context with respect to the inherent limits that exist for testing – even extensive testing – prior to release.

Okay, with that framing, detail about the setup / use case in consideration:

I recently decided to upgrade a Flint 2 (GL-MT6000), mainly for the hopeful benefit of the community so I could share about the experience. The Flint 2 was previously on 4.8.3 and was rock-solid on that firmware. I monitored for a while after 4.9.0 and 4.9.1 before deciding to give 4.9.1 a go (I'd already decided against 4.9.0) so I could report back to the community. Folks will obviously need to take this for what it's worth and compare against their own setup and use case to determine relevance, generalizability, etc.

This Flint 2 is a backbone device in a network that:

• has several VLANs (configured via bridge VLAN filtering under DSA)
• runs AdGuard Home (AGH) where AGH handles all client requests directly, uses the HaGeZi Pro list (this is the list even HaGeZi recommends: https://github.com/hagezi/dns-blocklists, and more ≠ better in terms of bloating your blocklists), has multiple client-level policies (including but not limited to differing DNS upstreams), and handles custom DNS rewrites and custom filters
• has VPN servers and clients

There is more, but those are key highlights.

Equally important is what this Flint 2 does not use:

• the new DPI functionality
• the parental control functionality (side note: AGH, properly configured, can often handle most if not all parental control needs)
• ACL rules via the GL.iNet UI (though it does have custom firewall rules implemented directly in LuCI)
• AmneziaWG
• GL.iNet's Guest or IoT networks or the Flint 2's WiFi, as the network uses VLANs (as already mentioned) and dedicated access points (side note: the Guest and IoT networks from GL.iNet are often referred to as VLANs; however, they are not actually VLANs, but rather, subnets, and these are different things; but direct VLAN support is coming in firmware 4.10, which is great to see).

4.9.1 has been running for over a week now (after making a backup of the 4.8.3 config and ensuring the 4.8.3 firmware was downloaded locally just in case). With one minor adjustment for the VLANs, 4.9.1 has been incredibly stable – no issues at all. I initially did this thinking I was just going to give it a go to be able to report back to the community and then possibly hop back to 4.8.3, but with as smooth as things have been, my current plan is to leave the Flint 2 on 4.9.1.

So, what about the VLANs? As most probably know, GL.iNet changed several things substantially in the 4.9.x bump. In the past, after I'd configured VLANs in LuCI, everything just worked automatically with GL.iNet (aside from the client display issue that I've harped on a bit previously, e.g.: https://forum.gl-inet.com/t/gl-inet-ui-shows-no-clients-connected-due-to-use-of-vlans/57994, https://www.reddit.com/r/GlInet/comments/1p50m6i/comment/nwcnl6m). However, when I first upgraded to 4.9.1, things were not working properly, but this was due to the custom VLANs and how GL.iNet rewrote things in 4.9.x. My backup behavior was important here, because I was able to immediately revert to 4.8.3 and restore everything within a few minutes. I wrote GL.iNet about my experience and noted the use of custom VLANs on the Flint 2 in question. They responded quickly and noted that, given how they changed things in 4.9.x, I needed to add a few lines to their route_policy config file. When I had time to re-upgrade to 4.9.1 and add those lines, I did that. And since then, things have been incredibly smooth.

What I did:

I'm sharing this for information only, so standard caveats apply: Make sure you back everything up first, I'm not telling you what you should or shouldn't do, make sure you know what you're doing, I'm not responsible for anything that happens, etc., etc. With that out of the way:

Within etc/config/, the route_policy config file in 4.9.1 is the one I tweaked at the advice of GL.iNet. The default appearance of route_policy in 4.9.1 should begin with something that looks like:

config policy 'global' option enabled '1' option service_policy_en '0' option mode '1' option instance_on '1' list append_source_if 'iot' 

All I did was add lines mirroring the line for the 'iot' interface for each of the VLAN interfaces. So, for VLAN interfaces 'foo', 'bar', and 'baz' (obviously not their real names), you'd want route_policy to end up looking like:

config policy 'global' option enabled '1' option service_policy_en '0' option mode '1' option instance_on '1' list append_source_if 'iot' list append_source_if 'foo' list append_source_if 'bar' list append_source_if 'baz' 

There are several ways to introduce these changes. For example, you can SSH into router and either issue uci commands (e.g., uci add_list route_policy.global.append_source_if='foo', then repeat that command for 'bar' and 'baz', then uci commit route_policy, then reboot the router) or edit the `route_policy` file directly (via vi or nano). You can also SCP into the router and edit the route_policy file.

Once I'd made those changes and rebooted the router, all the VLANs started showing up in AGH as desired (remember, this setup uses AGH to handle DNS requests directly).

For good measure, given how much they changed the VPN client / policy side of things in 4.9.x, I also tore these down and set them back up again. Quick work. I did this only for the VPN client side of things. I left the VPN servers alone, and they've continued to work just as they did on 4.8.3.

Conclusion

If you're still reading, sorry for the long post, but I wanted to give proper context. I hope this helps someone. And special thanks to the GL.iNet team for all the testing of 4.9.x and for the help from Bernard and the other folks behind the scenes who helped out when I submitted my query about getting 4.9.1 to work with the above situation!