Apologies, as I am sure this has been asked before, but thought I would ask about my specifci setup. My router crashed overnight, losing all WiFi and network connectivity, requiring a physical reboot to recover. After investigation, I think the issue is AdGuard Home causing a dangerous RAM spike during filter list updates. I do have quite a few blocklists however, my router still has around 450MB of free RAM, which should be more than enough.
I did temporarily remove HaGeZi's Threat Intelligence Feeds and my available RAM jumpt to about 670MB however, my router should easilt be able to handle this, so I'd rather keep it enabled.
What I did observe was that my RAM dropped dangerously below 50MB when HaGeZi's Threat Intelligence Feeds update was running, so I guess a LOT of RAM is being used only during the initial update. I am not sure why this is, but I think that this update crashed my router.
I usually had about 750MB of free RAM on my router with just a couple of blocklists running, but I wanted to add some more seeing that I have plenty of headroom.
Filter lists currently enabled:
HaGeZi's Normal Blocklist
HaGeZi's Threat Intelligence Feeds (1.5 million rules approx)
HaGeZi's Samsung Tracker Blocklist
HaGeZi's Xiaomi Tracker Blocklist
Perflyst and Dandelion Sprout's Smart-TV Blocklist
AGH is known to be very memory-hungry. This device can easily handle all those feeds if you use another adblocking solution for OpenWrt. For that matter, adblock-lean is IMO the most efficient in regards to memory use, especially during blocklist updates. (as the current maintainer of adblock-lean, I may be biased)
No GUI but it has a terminal-based setup wizard. Installation and initial setup are super easy - just follow the steps in the README, it takes approximately 1 minute to complete. Since you will probably want to modify the feeds, answer 'n' when asked whether to start adblock-lean. Then edit the config file: nano /etc/adblock-lean/config (you may need to install the nano package) and add whatever extra feeds you want to the value of the raw_block_lists config option. E.g. (based on what you wrote above):
Thank you! I just looked into the zram-swap solution and this seems like a sound plan. I've done this and set the GOMELIMIT=200MB as that should still leave my with plenty of RAM, or would I be better to reduce it to 100MB anyway? I'm not honestly sure what impact this would have.
Thank you! I've just implemented a potential fix which I will monitor and see how it goes however, if my available RAM continies to drop and this issue occurs again then I will seriously considering this alternative. A GUI is handy for quckly unblocking fales posistives and for checking performance stats quickly, but I do appreciate it should be function first.
Hagezi lists have relatively few false positives, and when those are found, users report them directly to Hagezi and he fixes such issues. As long as you do not disable automatic blocklist updates in adblock-lean, you will get a fresh version of the Hagezi lists daily. As to performance, I suppose it's nice to look at a pretty dashboard which gives you a satisfying number of blocked requests, but personally I've never found any need for that. The adblocking effectiveness itself is essentially the same.
Thanks. I guess it's just something I am so used to. You are right, I hardly ever get any false positives. How resource intensive adblock-lean? One slight annoyance I hace with AGH, thought it is probably caused by OpenWRT, is that it doesn't register quite a few hostnames on my network, so I have to manually specify them in Client Settings in AGH. In fact, where can I read more about adblock-lean? Thank you and sorry for all the questions!
I linked in my comment above to the project's Github page.
Depends on what you mean by 'resource' but generally - we (developers of adblock-lean) spent a lot of time optimizing every resource-related aspect of adblock-lean. So as I wrote above, IMO it is the most efficient adblocking option you have on OpenWrt in terms of memory use. In terms of blocklist processing speed (e.g. during automatic blocklist updates), I believe it is about as fast as any other option and possibly somewhat faster. In terms of system load when processing DNS requests, this is entirely performed by the DNS resolver. In the case of AGH, AFAIK it implements its own DNS resolver which I don't know much about. adblock-lean, in contrast, configures the resolver which normally comes bundled with OpenWrt - dnsmasq. dnsmasq is very fast and efficient. In short, I don't think you will have any noticeable lag in DNS resolution and the associated CPU load is negligible.
BTW if you do stumble across a false positive, you can easily unblock it with adblock-lean as well. Simply create a local allowlist file (the path is set in adblock-lean config; in currently latest stable version of adblock-lean it is by default /etc/adblock-lean/allowlist but the default path may change in the next release) and add any domains you want to unblock to that file. Then run service adlbock-lean start. That's the whole unblocking procedure.
The GL-MT6000 can handle AdGuardHome. Since this model features eMMC, reconfigure the AdGuard Home working directory (by default /var/adguardhome/, which resides in /tmp — volatile RAM) to a persistent location on the eMMC (e.g., /opt/adguardhome/) so that blocklists persist after reboot. Also install the zram-swap package, as large blocklists consume excessive RAM. Configure custom sysctl parameters, such as net.core.somaxconn, vm.swappiness, and TCP network tuning, to optimize the kernel. Use only one blocklist — HaGeZi Pro is sufficient. Huge and unnecessary blocklists drastically degrade DNS query latency and can exhaust available memory.
I would not recommend this. eMMC is a flash chip soldered to the logic board. As any flash storage, it suffers from wear and tear with each write/erase cycle. SSD drives fail because of wear and tear, and eMMC drives fail as well. But contrary to a modular SSD drive, replacing the eMMC device is not as simple as swapping out a module. You need a hot air station, soldering equipment and you need experience in microsoldering repair. (besides, you would need to extract the old firmware from the old chip and write it to the new chip, which requires yet another set of specialized equipment and skills)
I know all this for a fact because I do such repairs professionally.
understand your concern, and your technical expertise is valid. However, in this specific context, the risk is overstated.
The HaGeZi Pro blocklist is ~3 MB with ~180,000 hosts. At daily updates, that's roughly ~1 GB of writes per year, negligible for an 8 GB eMMC 5.1 with built-in wear leveling? For perspective, the OpenWrt itself writes more during routine operation than this blocklist ever would.
Your broader point stands for write-intensive workloads (persistent query logs, databases, frequent large-file rewrites). The recommendation here is specifically: one small blocklist, no persistent logging. Under these constraints, eMMC wear is a non-issue.
The OP wants to use additional lists, and IMO if the router can handle them then those extra lists are beneficial, especially the largest one - TIF. This would add up to a few dozen MB. Yes, this is still not much compared to 8GB, provided that the eMMC does wear leveling. But then we do not know which firmware the eMMC chip runs internally and whether wear leveling is actually implemented correctly in it or not. So I would minimize those extra write-erase cycles anyway.
I am not aware of literally anything in the stock OpenWrt firmware which would write any data on the persistent storage at all, unless directly and specifically requested by the user (e.g. they change some config option in luci). I'm not saying that nothing is written, just that I have never encountered anything like that, so I would like to see evidence of such routine writes.
I trust the eMMC in the GL-MT6000. For a chip to carry the "eMMC 5.1" designation and be sold as such, it has to pass compliance certification. Wear leveling is a mandatory feature of the standard, not an optional one. While I do consider it safe, this eMMC was designed for workloads like Docker, with adequate storage for that purpose, it's even been adopted by the Tomato64 project already. At the end of the day, it's the end user's call.
Thank you @antonk and @rgnldo for your comments on this. I have some personal experience of this on my last router. I had AGH storing logs on branded external USB sticks. I think I went through 2 of them before i realised what the root cause was. It's the constant log writing that destroyed them. I'm quite sure of it. Obviously a USB stick is going to be less durable than the internal eMMC of the Flint 2 but even so, it's not a risk I would like to take. It's kind of annoying that it has 8GB of space, but I am only using barely 100MB but even still, I would be gutted if the logs destoryed tge eMMC storage.
Agreed. eMMC 5.1 and later have wear levelling, to be relied on. Now i.g. it depends upon write freq, file system used and fill level of the eMMC. And of write distribution, of course. Here, sequential writes (like in typical log file, BTW) are even "best" for the eMMC, as OS-based blocking/caching reduces number of erase-write cycles. Totally random writes are the very worst. Anyway, it might be helpful to use package mmc-utils, to get up-to-date info about the life-time-estimation of the eMMC in use.
