A couple of things I overlooked (I know; wataslacker) :
SQM seems to have configuration problem (from my logs) : Thu Jun 11 08:38:01 2026 user.notice SQM: Starting SQM script: piece_of_cake.qos on br-lan, in: 60000 Kbps, out: 600000 Kbps Thu Jun 11 08:38:01 2026 daemon.err modprobe: failed to find a module named act_ipt
Thu Jun 11 08:38:01 2026 daemon.err modprobe: failed to find a module named act_ipt
Thu Jun 11 08:38:01 2026 kern.warn kernel: [337140.861025] HTB: quantum of class 10010 is big. Consider r2q change.
Thu Jun 11 08:38:01 2026 kern.warn kernel: [337140.870463] HTB: quantum of class 10020 is big. Consider r2q change.
Thu Jun 11 08:38:01 2026 kern.warn kernel: [337140.953418] HTB: quantum of class 10010 is big. Consider r2q change.
Thu Jun 11 08:38:01 2026 kern.warn kernel: [337140.962900] HTB: quantum of class 10020 is big. Consider r2q change.
Thu Jun 11 08:38:01 2026 user.notice SQM: piece_of_cake.qos was started on br-lan successfully
Thu Jun 11 08:38:18 2026 kern.warn kernel: [337158.209861] htb: cake qdisc 8006: is non-work-conserving?
Thu Jun 11 08:38:18 2026 kern.warn kernel: [337158.215377] htb: too many events!
Thu Jun 11 08:39:01 2026 user.notice SQM: Stopping SQM on br-lan
Thu Jun 11 08:39:23 2026 kern.warn kernel: [337223.302874] HTB: quantum of class 10001 is big. Consider r2q change.
Thu Jun 11 08:39:23 2026 kern.warn kernel: [337223.321766] HTB: quantum of class 10001 is big. Consider r2q change.
Thu Jun 11 08:39:23 2026 kern.warn kernel: [337223.331123] HTB: quantum of class 10010 is big. Consider r2q change.
Thu Jun 11 08:39:23 2026 kern.warn kernel: [337223.376210] HTB: quantum of class 10010 is big. Consider r2q change.
Flow Control → Data Statistics Y axis appears to be scaled arbitrarily. The numbers used have no clear relationship to the “Total Bandwidth” values provided. This would be more useful if it indicated actual Mb or Gb.
I find it interesting that the Beryl 7 is being updated in beta more often than the Slate 7. Still disappointing that the Mudi 7 is still not in beta, as that's the only device left that I can't use DoH and DoQ. Great news that v4.9 is now stable with the Flint 2, but I intend to replace this with the Flint 4.
Hi!
It sounds good. I think the ‘gateway for specific devices’ would make sense. Is it possible to disable the DHCP service on the MT2500? I´d prefer to use DHCP on the ISP router.
And there´s one statement in your docu which I don´t understand:
Why is it neccessary to route all traffic in the same subnet over the drop in gateway? The standard gateway only has to route packets to outside the local subnet. Maybe I do not understand complete how the drop in gateway works.
Without drop in gateway the normal behaviour is your main router answering to be the main gateway as reply, this happen when a client i.e your pc asks as packet communication.
When drop in gateway has been enabled, it spams the awnser reply, meaning... it responds faster than the normal gateway in where the client gets confused into thinking the drop in gateway is the one.
In my opinion it is kinda exploitive but yea , so with this kind of nature it is expected it goes route over this gateway there is not really much to control I would think.
Also it happens on ARP which is layer 2 by the osi model, I believe at this layer ips do not exist, this is probably also a reason, ARP is the protocol which translates a ip to a unknown mac address, meaning that everytime a device connects to a ip it uses arp to question whos mac address it is, so if the ip was the gateway the drop in response would be faster in a spammy/forced way replacing the mac, lan clients also see these replies and fall for the same pattern...
Well, I’ve tested it today. It works very good, and there´s no kind of exploid with the ARP protocol. I can see a correct ARP table on my PC. I think there´s no technical problem, the only problem is the docu.
The drop-in gateway works very good. The new flow control is enabled and working. The same matches to AdGuard.
I hope version 4.9 will restore the following features:
The NTP server configuration options in the UI.
BSSID randomization should support multiple options, like in the old version, such as randomizing once and not changing after restart, changing it every time it restarts, or changing it periodically.
I hope version 4.9 will restore the following features:
The NTP server configuration options in the UI.
BSSID randomization should support multiple options, like in the old version, such as randomizing once and not changing after restart, changing it every time it restarts, or changing it periodically.
Will Slate AX and Mudi 7 be able to run 4.9 with the VPN failover at some point? Very eager to use it on those. Not sure if the rollout for more devices is done on a dot release basis (e.g. 4.9.1) or if they might be available soon on 4.9.
What do you think about testing the current beta, 4.8.3? In my experience, the betas aren't really unstable. You’d get the latest features, and if you found any minor issues, you could post them here in the forum. It might be a win-win situation for everyone, and the stable version might even be released sooner.
Upgraded to 4.9.0 from 4.8.3 this morning for 4 hours and went back to 4.8.3.
Very poor 5ghz coverage and output… Places just 5 meters away from router and just 1 wall away , where I had full reception and 100mbps speed are now barely in range and 2-10mbps speeds.
The new features are really nice but … I’d rather have good and stable connection .
Today I´ve tested the content filter of the latest beta releases 4.9.0 (MT2500 and MT3000). Opening a blocked website the browser stays loading and loading until it runs into a timeout. I think it would make sense to send an answer back to the browser. Maybe an empty website an do this job. Please have a look at this behavior.
I have been running on the 4.8.2 beta this whole time. I had not noticed this newer release from a few days ago, but I regularly check the page (or I used to)
Reading the release notes, there are not much to see of actual improvement we have been screaming for on the device. But a new beta. That is at least something.
My GL-X2000 has just today, been taken out of my network, and replaced with a different brand.
Must be something else not configured correctly, I’m on 4.9.0 and have no issues with any devices. iPhone on 5 GHz showing 890 Mbps similar distance from router. Did you retain settings? If so, probably a good idea to set up your router from scratch when moving to V4.9.0 as this is a major firmware release and due to multiple overhaul and changes in the software. Retaining settings from a totally different firmware may cause issues.
Unfortunately, the VPN tunnel is established between my laptop and their entry point. This means that my Spitz can’t change how the network stack is functions on my laptop. This is the most common employer VPN configuration.
using a Brume 3 (GL‑MT5000) and recently upgraded to 4.9 Beta 2, the additions in 4.9 such as Content Filter, QoS, and SQM are really appreciated on this device. The Content Filter works well, but there is currently no option to add exceptions / allow‑listed domains. This makes it difficult to handle cases where the DPI engine incorrectly slows down or blocks certain websites.
Could you please confirm: whether domain exceptions / allowlist will be added to the Content Filter and when?
Thanks again for the great work on the 4.9 release!
, so with this kind of nature it is expected it goes route over this gateway there is not really much to control I would think.
