This is great information. I currently have WiFi disabled on the Flint 4 and use a TP-Link Deco mesh system for WiFi. Being able to use the EasyMesh capability natively, with the Flint 4 just seems neater.
ETA: Scrap that. The Deco devices I have don’t use EasyMesh.
You folks never cease to amaze and please…
The new Spitz 4.11b1 is mos’ wondermous! The new UI is in most ways, much improved over 4.10.
Internet : as with 4.10, very clean & clear UI
DNS :
I have mixed feelings about having DNS as a menu item separate from Network, but I can still sleep at night. I do like that you’ve combined all networks DNS settings here, though.
Options: one of the functions I enabled that hurt my connectivity was “Override DNS..”, which appears to block unencrypted DNS traffic behind the gateway. Can I assume that encrypted DNS (DoT, DoH) should be unaffected?
a minor quibble: if the “Settings” gear icon only has one sub-option, it should take you there when you click on the icon. The current design is the UI equivalent of a numbered or bulleted single sub-paragraph (confusing). My suggested behavior is found in Flow Control → Network Quality
Please consider including VLAN configuration when adding/editing WiFi networks. This will greatly improve workflow. It’s nice that they’re also grouped under Network → LAN, but it’s inconvenient when they’re missing from Wireless
Mesh: Beautiful addition! I just wish I had a mesh deployment to test it…
Clients: Same observation I had got 4.10: Please list all IPv4 addresses encountered. This is done for IPv6
Cloud Services:
GoodCloud binding to the services is much more consistent than in 4.10 (would sometimes fail with unclear messaging). Extending some of the GC manglement features to the gateway is also very helpful
The GL.iNet Account → GliNet item isn’t clear that it only takes you to an app download, and it doesn’t say that the app isn’t up to speed with the beta release.
VPN: I’ve always wondered why ZeroTier isn’t here, but instead is found under Applications. Also, because I don’t use any of the listed services, I can’t test them
Network
Multi-WAN: because the router is using these settings to initiate failover, gateway switching, or (in my case) cellular redial, it makes more sense to test the ISP-provided gateway and local DNS. This ensures that decisions are made “as close to home” as possible. For example, failure to reach the default hosts (1.1.1.1, 8.8.8.8, etc.) is only an indicator of those responsiveness of those hosts or connecting networks; not necessarily the ISP connection itself. When I change these to the TMHI-provided gateway and DNS, and I encounter many fewer redials. Of course, YMMV: recently, my TMHI gateway recently started ignoring ICMP ping requests, and the DNS servers are inconsistent, so I disable this check entirely.
LAN: Nice VLAN addition and summary information! I’ll have to play with this, sine I also separate my guest and iot nets using 802.1Q vlans…
Ethernet Port: This is also a good summary UI, but the color usage is inconsistent. The legend indicates that light blue is active (up), while gray (grey) is inactive (down), but these colors are not used in the same way in the icons:
The inactive WAN port ethernet port image is grey (inactive) surrounded with dark blue, while the active LAN port ethernet port image is dark blue surrounded with light blue (active). The color usage is reversed between states. Either the port state color should be used for the ethernet port image, or the surrounding area, or vice-versa, but not both.
Flow Control
Network Quality - beautiful addition: well constructed and very clear for the most part! It occurs to me that the data collected here would be a far better trigger for the Multi-WAN feature as it would be able to distinguish between tests for local and remote hosts.
WAN Gateway - because my ISP gateway ignores ping requests, this measurement is irrelevant and potentially confusing.
Please add an “ignore this” option for each measurement factor so that the user can remove known false negatives like this…
Because the router receives no ping responses from my ISP gateway, the 1000 ms indication is false. This would be clearer in this case if it indicated “no resp” (not sure how easy your graphing SDK would make this)
UL/DL graph: nice general indicator, but the KB/Kb selection isn’t persisted between logon sessions
Speed Test - please persist the last speed test values between logon sessions
Data Statistics: still appears to be an excellent indicator of general traffic profile, and I like the addition of chart type selection (line, bar, pie)
Content Filter - a lack of block action logging makes this very difficult to evaluate or troubleshoot
QoS -
I like the "Speedtest” addition here (and in SQM). My only suggestion would be to indicate what test / service is being used and to remind the user to run it multiple times to account for network performance variations.
You dun dood it: you added network-based controls, but Device Priority lacks the ability to specify sources currently unknown to the router (manual entry)
I like the increased granularity of the settings here, but it’s unclear what mechanism is in used for this feature?
SQM - truly “smart” now with Cake Autorate. I’m still playing with QoS, but I’ll dig around here as time permits…
QoS / SQM: Please create a “At least one conflicting feature is in operation; would you like to disable it/them?” popup in the case where the user tries to enable either one while the other is enabled, and if the response is “Yes” then disable the conflicting feature.
Parental Controls: there are never any childebeasts here, so we don’t use it
Security
Security Scan
most excellent addition, but how is the overall score calculated? For example, my router has DPI disabled but this produces a score of 98; not what I’d expect from a ratio of 13:14 (93% rounded to 1)
Please provide a list of the settings tested in the UI. They move too quickly in the Test/Retest process for anyone to recall, much less review them
UPnP - This is more properly included in Flow Control. I can see how some might find this useful, but I never have. It’s a massive attack vector from inside, and thank you for including that warning…
General: I’d like to see some more explicit debug logging for the kmwan tests. I always change the kmwan test IPs to use my ISP gateway and DNS services as advertised in their DHCP service. This is much more meaningful than making gateway functionality decisions based on tests against hosts in distant networks.
For the DNS option: yes—Override DNS Settings for All Clients applies to unencrypted client DNS. Client-originated DoT or DoH traffic is not redirected by this option, although separate firewall or content-filtering rules could still affect it.
This differs from selecting Encrypted DNS on the router: clients may send ordinary DNS to the router, while the router encrypts the upstream DNS connection. Your other UI observations and feature requests are clearly documented for staff review.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
There is currently no confirmed ETA for Brume 3 (GL-MT5000) firmware 4.11. The rollout is being expanded by model, but no Brume 3 release schedule has been announced yet.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
I’ve upgraded my GL-MT6000 Flint 2 to firmware version 4.11. Under the mesh settings I’ve set it up as “Main Router”. I also upgraded my GL-MT3000 Beryl AX to firmware version 4.11 and under the mesh settings I’ve set it up as “Mesh Node”.
From what I can tell, everything is working. I see some devices connected to the main router and some to the mesh node. However, when I try to view the admin page of the mesh node router, I get a message saying the site cannot be reached.
If I logon to Goodcloud, I can get to the mesh node router (Beryl AX) throught the Remote GUI.
Not sure why I can’t access the mesh node router with the IP address?
After the Beryl AX has been added as a Mesh Node, its original standalone IP address is no longer used for local administration. The node is managed through the Flint 2’s Admin Panel:
Open Mesh on the Flint 2.
Select the Beryl AX node in the topology.
Click the gear icon and choose Open Admin Panel.
This should open the node using the IP address assigned by the Flint 2. GoodCloud access working confirms that the node itself is online. More information is available in the Mesh guide.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
If Open Admin Panel from the Flint 2’s Mesh page also fails, please check the Beryl AX’s current IP address in the Flint 2’s Clients list or Mesh node details. Then, while connected to the Flint 2’s LAN/Wi-Fi, try opening that current address directly—first with http://, and then with https:// if necessary. Do not use the Beryl AX’s former standalone LAN address.
Please report the address shown by the Flint 2 and whether the failure occurs only through Open Admin Panel or also when entering that current address manually. Do not post any MAC addresses or passwords.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
Anyone else having issues with Wi-Fi repeater mode since upgrading to 4.11? Mine now fails to connect to Wi-Fi networks that it connected to fine before the update.
Please test Repeater against a phone hotspot—first on 2.4 GHz, then on 5 GHz. This will distinguish a general 4.11 repeater failure from compatibility with the original upstream Wi-Fi.
Please report the router model, complete 4.11.1 beta build number, whether the networks appear in the scan, and the exact error shown after selecting one. Also note whether the original 4.11 upgrade retained settings; do not post the Wi-Fi password.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
Interesting, I have it connected to a new network (as travelling) and it works, but the network which was working BEFORE the update, stopped working AFTER the update. So there is something going on. Hopefully can get a better answer than just the AI bot
This is using DoQ/Quic via quic://dns11.quad9.net:853 works perfectly but if I use a DNS stamp for the same configuration dns lookup info 1000ms , if using nextdns in any form it also does the 1000ms just to clear it up for you guys, I’m also running 4.11.1 beta
Just reporting back that I can now access the Beryl AX (node router) through the admin link on the Flint 2 (main router). Not sure why it’s working now? The only thing I can think of is both routers are on scheduled reboot on Sunday morning. That must have cleared the issue?
I did reboot both routers after setting up the mesh. Thanks.
We’ve reviewed all your comments in detail. Some of these features and optimizations are already in the works, while others have been long-standing hurdles for us.
Either way, we take every single suggestion and issue seriously.
One thing I forgot to mention: when viewing the Cellular → Details and Configuration, the IPv6 addresses are wrapped, rather than displayed on a single line:
I just encountered an odd issue with my Flint 4 on Beta 3 and a Deco BE25 mesh system.
Originally, the Deco system, all with ethernet backhaul, had the main node connected to a Zyxel 2.5Gb/s switch which is in turn connected to port 2 on the Flint 4. I wanted to connected the Deco node directly to the Flint 4 as I have several 2.5Gb/s ports available. I connected it to port 4 and the router became unresponsive, via the GUI.
A few seconds later it came back again and I noticed that none of the satellite Deco nodes were connecting via ethernet. Several restarts of the Deco system and a restart of the Flint 4 didn’t change that situation.
I then unplugged the main Deco node and plugged it back into the Zyxel switch, restarted the Deco system and they’re now all connecting via ethernet again.
I’ll have another go later and try and connect all the backhauls to the Flint directly, to see if that changes the situation. Not that it should have any bearing…