Flint 2 v4.9 Firmware Released mt6000-4.9.0_release1

Router
1

v4.9 is release now I see for local or online upgrade.

Filename:

mt6000-4.9.0_release1-1015-0605-1780626850.bin

I will try this myself later once I finish work.

Perhaps we can gather experiences here and save each other some pain?

1 Like
2

Release notes here:

3

I probably won’t need much of what this upgrade brings, but I’ll sit on this for awhile and let people who know (or maybe think they know) test this out. At some time my OCD will torment me enough to say “to heck with it” and throw caution to the wind…

1 Like
4

You’ll at least need the SQM.

5

My experience so far:

I upgraded from 4.8.3. I already had the wifi country code set to GB via LuCI (as that is my location). Post upgrade I do not have any notable degradation of wifi.

My Tailscale binding remained intact. My Firewall rules defined in LuCI remain all good and pretty much all other config I have checked all seems to have retained as expected (parental controls excluded as per release notes).

Network/wifi options are enhanced with it now possible to add more SSIDs without resorting to LuCI.

On 4.8.3 I had SQM installed and enabled (managed via LuCI). Now SQM is in the main settings under Flow Control. For me it was enabled but had no values set (which is not a possible combination via the GUI). Here there is a little bit of a draw back as unlike before, you have to enable for either both upload and download (which is generally not necessary, or not enabled at all. Also the values are in Mbps not kbps so it’s not as granular as I was used to. For now I have set my download value set to 10000 opposed to my actual download to prevent it throttling that when I don’t want it to.

I will enable a IoT SSID when I can be bothered to move my IoT devices over.

6

For me the upgrade from v4.8.4 → v4.9.0 instantly broke my main wifi SSID. None of my devices would connect to that SSID anymore. I already made an seperate IoT network, devices connecting to the IoT and Guest SSID’s had no issues at all and had internet access as well.

It seemed to be an authentication issue since devices wouldn’t even connect to the SSID.

There didn’t seem to be any (IP) conflicts either and i just couldn’t get it to work, even not after disabling other radio’s (SSID’s). Logging was inconclusive as it didn’t contain any logging containing the troubled SSID.

For now i reverted back to v4.8.4 and got my network up and running again. But i also had to restore my previous config via luCi, because the upgrade to v4.9.0 broke that as well.

I emailed support to see if they have more reports and maybe know whats causing this.

8

Well, that certainly didn't last long. My OCD was driving me right “spare” so I bowed to temptation and upgraded the firmware on my Flint 2 to 4.9. So far so good, not experiencing anything bad, all working normally. However, I see all sorts of neat stuff I can break and come back here to beg for HELP!!

I will dutifully wait until 4.9 is released for the Slate 7 (the Flint 2 is the “family” router and the Slate 7 is my personal “experimental” router) and try out all the settings to see what works and what doesn’t. You may be hearing from me soon…

1 Like
9

Naa, I have faith in you bro :oncoming_fist:

1 Like
10

Gave in to the temptation to try and did a fresh install. Was just about to post that it has been working great before I started having random and unexplained internet disconnects. Rapidly lost faith and went back to the OP24 version as that has been more stable for me.

11

Even though firmware 4.9 shows TX power as 20 dBm, it does not necessarily mean the WiFi signal is stronger than in 4.8.3 where it showed 15 dBm.

TX power is only the theoretical transmit limit, not the real-world performance. In practice, WiFi strength depends on many other factors such as driver changes, radio calibration, noise handling, beamforming, and scheduling.

It is very possible that 4.8.3 feels stronger because it may have used a more aggressive or less restricted WiFi driver tuning. Older firmware often allows more “burst-like” transmission behavior, which can feel like better range or stronger signal even with a lower displayed dBm value.

In 4.9, the system may prioritize stability, interference reduction, and regulatory compliance more strictly. That can result in slightly weaker perceived signal or less “punchy” WiFi, even though the reported TX power is higher.

So in short: higher dBm in the UI does not always equal better real-world WiFi performance.

12

It’s a bust from me. I’ll be downgrading again I think. Feels like a step backwards:

  1. AdGuard enabled simply does not work. I’ve reduced the blocklists and it improved a bit but I think there is a big memory constraint or something.

  2. Enabling DPI limits download and upload to about 600Mbps. I’m kind of ok with accepting the extra processing work that is being done but pain vs gain isn’t worth it for me so this is a not a valuable feature for me.

  3. Not done exhaustive tests but it feels like WiFi is weaker.

Of course sitting on an old firmware isn’t viable long term so I really hope these issues are ironed out. Feels like 4.9 isn’t ready for prime time.

I’m happy not using the DPI features but AdGuard Home issues will need to be resolved before I’m prepared to use it. One viable solution is maybe a combination of a few small specialised block lists that are important to me and an outside DNS that blocks the bulk of the gambling and malware stuff. Shame though as this just worked on previous firmware versions.

Bottom line is that 4.9 is breaking features I want to use and adding features I’m not especially interested in.

13

I think it’s definitely a resource constraint on AdGuard. Pruned my blocklists and rebooted and things have improved somewhat. Don’t really have time to mess about with it today but will see what happens over the next few days.

14

My experience has been very similar.

After upgrading to 4.9 I ran into several issues that simply were not present on 4.8.3. AdGuard Home became unreliable and DNS behavior was inconsistent. I spent quite a bit of time troubleshooting DNSMasq, AdGuard and Multi-WAN interactions, but in the end I could never get the same stability that I had on 4.8.3.

I also noticed significantly weaker Wi-Fi coverage. In the exact same location (about 12 meters from the router), my signal levels were substantially better on 4.8.3 than on 4.9. After downgrading and doing a clean installation of 4.8.3, the stronger signal immediately returned.

SQM was another area that raised concerns. While I understand the additional processing overhead, the overall benefit did not justify the performance impact in my setup.

What convinced me most was a clean test. I reinstalled 4.8.3 from scratch and configured only the basics: WAN, WWAN failover, Wi-Fi, DNSMasq, NAT acceleration, GoodCloud and Multi-WAN. The router immediately became stable again. DNS worked correctly, Wi-Fi coverage improved, and overall behavior was much more predictable.

I appreciate the new features introduced in 4.9, but at the moment I feel that some existing functionality became less reliable. For my use case, 4.8.3 remains the more stable firmware until the AdGuard, DNS and Wi-Fi related issues are fully resolved.

15

I did some more testing and as far as I can see it is leaking DNS queries. I have blocklists for gambling sites and on testing, DNS resolution sits there for a bit and then after about 30 seconds sends you on through to the site. Both the AddGuard blocklists and the DNS provider (Mullvad Family) should have blocked the DNS request. Guessing the DNS request was resolved using ISPs DNS servers???

In so far as I can tell it bypasses AdGuard when AdGuard fails to respond in a timely fashion. When it falls back it also fails to use the manually configured DNS server. I’m not bothering trying to test anymore, have downgraded.

I did not definitively determine how the DNS was getting resolved so I guess it may have fallen back to some alternative DNS but I certainly wasn’t getting the behaviour I expected. I also can’t rule out it was my incompetence, just that 8.4.3 behaves as I expect in the same scenario.

16

That is very interesting and would explain some of the behavior I was seeing.

I also spent quite a bit of time troubleshooting AdGuard, DNSMasq and Multi-WAN interactions on 4.9. While I did not perform a formal DNS leak test, I repeatedly saw situations where DNS behavior was inconsistent and difficult to predict. At one point I even ended up with complete DNS failure after changing the forwarding chain.

If DNS queries are indeed falling back to ISP DNS when AdGuard becomes slow or unresponsive, that would explain why filtering appears to work initially and then suddenly stops working after a delay.

What makes me confident that something changed in 4.9 is that after downgrading to 4.8.3 and doing a completely clean configuration, all of those DNS-related issues disappeared. WAN, WWAN failover, DNSMasq and the rest of the network stack became stable again.

For now I have also stopped testing 4.9 and stayed on 4.8.3. I don’t mind new features, but DNS reliability is one of the most important functions of a router. If users cannot fully trust that DNS requests are going where they are supposed to go, that is a much bigger issue than losing a bit of performance.

Hopefully GL.iNet can reproduce these reports and investigate the AdGuard/DNS behavior more closely.

17

I think I’ll have another go when I get some enthusiasm. I think I’ll end up hosting AdGuard Home externally on a Pi (silly prices at the moment) or more likely a thin client. I don’t really want to add another box - trying to get rid of boxes and cables, not add new ones, but I suspect that will be the solution anyways. I don’t run a NAS, otherwise I’d host it there.

I’m conscious my testing was rushed due to time constraints, Need more time to have a proper look at it.

18

Created an account just to add this. I’m aslo going back as I’m still having issues were the router stops resolving DNS queries becuase of the Adguard problem. Never had this issue before this update.

19

If it helps anyone, I had a lot of custom settings in my AdGuard configuration, and going back to 4.8.3 caused AdGuard to fail to start because the config schema had changed. Here's what I did to fix that. This is overkill for most people, but I definitely didn't want to reconfigure everything from scratch, and I wouldn't have remembered all of it anyway.

https://gist.github.com/jaas666/70d21090997cb7d3eae676be0c805ff0

1 Like
20

couldn’t you just stay in 4.9.0 and update adguard using the script?

21

What script?