What's new

[Beta] Asuswrt-Merlin 384.11 Beta is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

384.11 Beta 2 is now available.

List of changes since Beta 1:

Code:
fa828bc7b8 (tag: 384.11-beta2, master) Updated documentation
3e6c8760a1 webui: remove other dead symlinks for IPTV page
a79a4a3162 netool: enable Netool support for all models
b582bbaa7e (origin/master, origin/HEAD) rc: let router implicitly use dot w/o caching resolver
bcb7240f4b httpd: report BCM490x CPU as Cortex A53 instead of B53 to reduce confusion
f9ca291edf httpd: fix out-of-bounds read in handle_request()
b5d582b7a7 rom: removed seldom-used unfiltered Quad9 DNS, added secondary filtered servers for consistency
ce7c29c719 webui: format DFS elapsed time string
62f37c9119 webui: fix undefined element JS error on Netstat page
ecf0ff7095 webui: implement netstat-nat support to the new netool-based Netstat page
c59666eaef rc: fix traceroute path
08855d28a4 webui: add Netool-aware pages to the RT-AC86U
125c222cd5 webui: remove dead symlink in RT-AC86U sysdeps
33b3aac661 build: re-enable NETOOL for RT-AC86U
7d4abd8a17 httpd: fix incorrect mimetype for wcdma_list.js and help_content.js (fixes #305)
80a0f5a7f3 webui: only restart upnp if firewall isn't getting restarted
437ed37f87 rc: do not restart firewall when restarting time services
ef2ffc5403 webui: note that IPv6 is not supported by ntp redirection
e04bbf7a6c rc: use REDIRECT target instead of DNAT to intercept ntp traffic, as it's more efficient; fix incorrect nvram check
4eb08896e8 webui: hide option to disable scheduled new FW checks; fix contextual help
026561390d webui: hide ntpd settings if not supported
0a83fb9857 ntpd: implement option to redirect LAN requests to the router
43611e5586 rc: add ntpd flag to rc_support
6810e52f68 rom: Updated DoT presets
dbfbc26a18 rc: wanduck: fix possible name buffer overflow
bcae5f99bc Bump revision to beta 2
ff00c0baee kernel: fix squashfs false-positive decode error
21c1d0ed57 rc: rename stubby.add custom config to stubby.yml.add for consistency
37c0f140c6 rc: stubby: rely on openssl to locate the CA bundle
e8884dff07 rc: remove support for replacing stubby.yml
So if ipv6 is enabled the ntp redirect will not work? Or will only work for ipv4 connection?
 
I can confirm that the NTP process interception works perfectly on the AX88U 384.11 beta2 !! ;):)
How did you test this feature so I can compare results I get?
 
Bad idea, since Apply restarts your entire WAN connection. Not a proper way to add 2 servers. Plus, the current design works the same way the presets have been working on the virtual server pages for many years (until the recent redesign).



Not supported by stubby, and adding another separate stub for DoH is out of the question. If Stubby ever adds DoH support, then it will be evaluated. Personally I'm not a fan of DoH, as it's a bastardization of established standards.
Stubby boast that eventually it will.support doh.
 
Beta 2: Client list still shows ZERO. Multiple browsers. Cache cleared. RT-AC1900P
 
How did you test this feature so I can compare results I get?
I have a security system that is always syncing time on port 123. Since enabling this new feature there are no port 123 requests so far showing as they used to in QOS classifications tab> tracked connections.
 
I have a security system that is always syncing time on port 123. Since enabling this new feature there are no port 123 requests so far showing as they used to in QOS classifications tab> tracked connections.
Is there away to tell the router to not allow ntp checks via ipv6 so that way ntp relies only on ipv4?
 
Beta 2: Client list still shows ZERO. Multiple browsers. Cache cleared. RT-AC1900P

When was the last time you did a full reset to factory defaults? As you seem to be unique with this issue persisting, it seems like that may be what needs to be done to show your clients.

I would wait to do so when 384.11 goes final though. :)

Please see my link in my signature below for a full reset to factory defaults following the M&M Config guide.
 
Is there away to tell the router to not allow ntp checks via ipv6 so that way ntp relies only on ipv4?
If IPV6 is your default then I don't see a way around it.
 
When was the last time you did a full reset to factory defaults? As you seem to be unique with this issue persisting, it seems like that may be what needs to be done to show your clients.

I would wait to do so when 384.11 goes final though. :)

Please see my link in my signature below for a full reset to factory defaults following the M&M Config guide.
i have seen where old incompatible switches were used on a network and it cause this issue too, especially if it is between the router and the rest of the devices.
 
If IPV6 is your default then I don't see a way around it.
no ipv6 isnt default it is just running as well as ipv4, my concern is the ntp request being sent out via ipv6 instead of ipv4 does the router block ntp request being sent out via ipv6?
 
Last edited:
Beta 2: Client list still shows ZERO. Multiple browsers. Cache cleared. RT-AC1900P
I had one client that didn't want to show up until I rebooted the client.

I could stream internet radio to it which means the router created a Nat table for it but still wouldn't add the device to the client list.

What is the client list populated by?
Dhcp requests? Ping scan of routers IP Range? Client broadcasts? Seems like watching Nat table would be good?

I assume depending on a devices behaviour it might be undetectable for long periods. A reboot likely forces the device to do a bunch of broadcasts like dhcp which allows the router to find it.
 
I have about 20 devices on my network, so a reset is burdensome. I'll end up doing it I guess. It only started with the Alpha. The client list has always been unreliable per Asus bugs, but it's never been zero. Other screens show clients in offline mode. FWIW, they all appear to be connected.

I don't want to derail the discussion here, as I truly appear to be the only one with the issue. If someone wants to PM me or point me to a method to force things to repopulate, I would be grateful. Thnx.


I had one client that didn't want to show up until I rebooted the client.

I could stream internet radio to it which means the router created a Nat table for it but still wouldn't add the device to the client list.

What is the client list populated by?
Dhcp requests? Ping scan of routers IP Range? Client broadcasts? Seems like watching Nat table would be good?

I assume depending on a devices behaviour it might be undetectable for long periods. A reboot likely forces the device to do a bunch of broadcasts like dhcp which allows the router to find it.
 
I have about 20 devices on my network, so a reset is burdensome. I'll end up doing it I guess. It only started with the Alpha. The client list has always been unreliable per Asus bugs, but it's never been zero. Other screens show clients in offline mode. FWIW, they all appear to be connected.

I don't want to derail the discussion here, as I truly appear to be the only one with the issue. If someone wants to PM me or point me to a method to force things to repopulate, I would be grateful. Thnx.
See this post and the one below. I have used it twice with almost 30 clients and it restored all perfectly.
https://www.snbforums.com/threads/backup-manual-dhcp-list.12876/page-4#post-469459
 
It has been a big month in this little corner of the world, between all the alphas here and Jack Yaz’s script explosion and updates elsewhere and all he collaboration by the devs to keep the community churning along. It’s like a critical mass has been achieved.
I wonder how the folks at Asus are feeling about all of this?


Sent from my iPhone using Tapatalk
 
It has been a big month in this little corner of the world, between all the alphas here and Jack Yaz’s script explosion and updates elsewhere and all he collaboration by the devs to keep the community churning along. It’s like a critical mass has been achieved.
I wonder how the folks at Asus are feeling about all of this?


Sent from my iPhone using Tapatalk
the big question is how much do they care?
 
Asuswrt-Merlin 384.11 Beta is now available for all supported models. This release features a number of significant changes.

May 2nd: Beta 2 is now available.
Traceroute not working properly.
traceroute.jpg
 
can automatic firmware checks still be disabled?
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Staff online

Top