Recent content by aru

I really enjoy reading RMerlin’s reviews and outlooks on firmware development. He frames it as a journey throughout the year, almost like writing a diary, rather than a cold, dry changelog. Not only does he recap past improvements, but he also mentions the development pace and potential updates...

Kudos to the Merlin team! Saying goodbye to AiCloud keeps our routers cleaner, safer, and more controllable. Thanks for keeping user security a top priority!

I think Diversion's reports are very comprehensive, allowing you to see the domain usage and blocking status for each device directly. I haven't used Pi-hole myself, so I'm not sure if it can provide similar functionality.

Ah, I see — thank you so much for taking the time to analyze and explain this. I really appreciate it! :)

You're right, .arpa isn’t only for private IPs, and it’s possible some of the lookups are generated by the router itself. I checked the NextDNS Logs, and there actually aren’t that many .arpa queries — most of them are old (around mid-September). No new ones have appeared recently. However...

By default, DNS Director is enabled and the router is set to Router mode, so internal devices should theoretically be unable to bypass the router—but in practice, it seems they can. Since SDN and Guest Network Pro are not used, .arpa queries will not originate from SDN or Guest Network Pro...

Yes, it is disabled on my WAN DNS Setting. As per your suggestion, I added local=/168.192.in-addr.arpa/ to /jffs/configs/dnsmasq.conf.add and restarted the service with service restart_dnsmasq. After monitoring for a day, I noticed that the query volume remained unchanged. if it’s possible...

I noticed that some devices are sending upstream in-addr.arpa queries, including certain IoT devices and AiMesh nodes. Since these queries consume my NextDNS query quota, I’d like to know if this behavior is considered normal. Also, is there a way to configure the system so that in-addr.arpa...

Thank you for your explanation. I have checked the router’s NVRAM parameters, and wl_bw_switch_160 is set to 2, indicating that TDCS is indeed enabled and has not been modified or disabled. Therefore, the current ability to maintain stable 160 MHz operation is likely not due to TDCS being turned...

In previous firmware versions, even if the bandwidth was set to 20/40/80/160 MHz with DFS channels and auto channel selection enabled, devices could initially connect at 160 MHz. However, after about 5–10 minutes, radar interference would be detected, and the connection would automatically fall...

The RT-BE88U (4x4, external antennas) has such strong coverage that it acts like a magnet, “holding onto” client devices. Even when a device moves right next to the RP-BE58 (2x2, internal antennas), it may not let go. In addition, the wireless backhaul cuts the available bandwidth in half...

Thanks for developing vnStat! It’s been a very reliable and lightweight tool for long-term network traffic monitoring. Currently vnStat shows RX/TX/Total traffic, which is great for historical usage tracking. However, for users who want to understand whether their subscribed bandwidth is...

Considering the limited resources of my router, I have been consistently using the default standard blocklist while periodically reviewing the Diversion Statistics Report. Whenever I notice domains with tens of thousands of hits related to ads or tracking, I add them to my blocklist...

Thank you for the information. The default configuration file that comes with the Unbound installation package is already quite comprehensive, having been fine-tuned by many knowledgeable and dedicated contributors. It also includes numerous optimizations specifically tailored for the ASUS...

Thank you for your detailed explanation. So it turns out the change to serve-expired-client-timeout is what affected the caching behavior — this information is truly essential. It really helped me understand the issue. Thanks again! 👍 As it turns out, this change in the newer version was...