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!

yea so cloudflare and my ISP both have servers here where I am. Ping is relatively the same one may be a couple of milliseconds off from the other at all times. now if i use quad9 my servers are then located in Miami which is 348 miles away. the difference in ping in those is about maybe 8~10 milliseconds and google follows shortly behind. Google servers are all the way in north carolina and texas---Imagine the distance on those.

In a major metro area, all the major vendors and CDN's will have a presence.

For example, I live in the Greater Toronto Area, about 35km away from the downtown business district - where a major multi-tenant data centre exists. Cloudflare is there, so is Google (DNS & www) as well as OpenDNS, Netflix, etc.

As a result I get better pings to the Cloudflare DNS compared to my ISP DNS. (9-12ms ping to 1.1.1.1, 13-14ms ping to my ISP DNS). I also get 15ms (or better) pings to Quad8 (Google dns), www.google.com, etc.
 
And as soon as some client connects, it stops..?

ACSD is Broadcom's Automatic Channel Selection Daemon.
 
Dnssec via dnsmasq
Code:
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d2a6n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d1a3n1.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d1a6n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d3a6n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d2a6n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d3a3n1.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d3a10n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d3a3n1.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d1a6n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d1a3n1.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d3a14n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d3a5n1.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d4a6n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d3a5n1.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers

These are from testing here https://rootcanary.org/ with cloudflare as resolver
upload_2019-5-2_16-27-52.png

I get the same results using Quad9 minus all the error messages inside the sys log

This is from using dnssec from stubby.yml

upload_2019-5-2_16-48-7.png

just some interesting tests.
 
In this beta, in my AC86u, udpxy is not autostarting.

I have Movistar iptv profile but I had to add udpxy call at services-start script.
 
I know that, but why does it do it only with no clients connected?

Probably to avoid disconnecting them if it decides to change channel? Only Broadcom would know.
 
  • Like
Reactions: MDM
Dnssec via dnsmasq
...

These are from testing here https://rootcanary.org/ with cloudflare as resolver
...
I get the same results using Quad9 minus all the error messages inside the sys log

This is from using dnssec from stubby.yml

View attachment 17386
just some interesting tests.

The errors are from the servfail response with GOST when using DNSSEC via dnsmasq?
 
In this beta, in my AC86u, udpxy is not autostarting.

I have Movistar iptv profile but I had to add udpxy call at services-start script.

Did you provide a port on the IPTV page?
 
I get the same results using Quad9 minus all the error messages inside the sys log

Disable DNSSEC validation of unsigned replies, you'll get the same results as with Stubby.
 
Dnssec via dnsmasq
Code:
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d2a6n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d1a3n1.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d1a6n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d3a6n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d2a6n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d3a3n1.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d3a10n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d3a3n1.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d1a6n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d1a3n1.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d3a14n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d3a5n1.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d4a6n3.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
May  2 16:14:37 dnsmasq[21778]: Insecure DS reply received for d3a5n1.rootcanary.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers

These are from testing here https://rootcanary.org/ with cloudflare as resolver
View attachment 17385
I get the same results using Quad9 minus all the error messages inside the sys log

This is from using dnssec from stubby.yml

View attachment 17386
just some interesting tests.
I always have bad results with that test using CF, CB, and Q9. Haven't tried Q8 yet. Not sure why it fails.
 
Disable DNSSEC validation of unsigned replies, you'll get the same results as with Stubby.
I knew it had to be something about dnssec with dnsmasq that is better
 
The errors are from the servfail response with GOST when using DNSSEC via dnsmasq?
Yes using ghost with those specific signings. So it turns out that dnsmasq dnssec is much stricter.
 
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
 
New things to test with Beta 2:

- Network Tools got updated versions of the Analysis (now with a visual ping) and Netstat pages (new settings layout). These are based on Asus's Netool daemon which they had enabled on some models, but never updated the webui pages to make use of it, except on their ROG models.
- The router can now intercept NTP client requests, and redirect them to the router's own NTPD.
 
Just did a dirty and a clean update to beta-1 on an RT-AC86U - since then my Android phone shows up as 2 devices connecting under the same name - sometimes on 2.4, sometimes 5 Ghz - never happened or saw that before. Router has been rebooted, phone has been rebooted, problem does not show under 10_2. And yes, did manual config after factory reset. Went back to 10_2 for now

Same problem here using 2 x RT-AC86U with second configured as an AP... did not show under 10_2 either.
 
Probably to avoid disconnecting them if it decides to change channel? Only Broadcom would know.
I do have channel change with clients connected too, but only occasionally, and without those (or any) messages in log..
 
I can confirm that the NTP process interception works perfectly on the AX88U 384.11 beta2 !! ;):)
 
I got stuck with the DNS over tls ui for a minute.
I figured you enable, then pick provider then click apply.

Took me a while of confusion for why the page would come back with nothing selected.
Obviously I now know the process is enable, pick provider(optional), click add below where provider was added then apply.

How about if you pick a provider then click apply that is does the add bit for you?


Also is it possible to add DNS over https to our routers in the future?
As far as I understand the 2 encrypted DNS standards are competing for relevance.
DNS over tls argues DNS requests should be obvious so they can be managed by external parties easily.
DNS over https argue that DNS should be hidden in the noise of all https data so it is hard to manage by external parties.


DNS over Https also supports encrypted sni which without basically makes the entire point of DNS over tls pointless as it is obvious what dns is being requested/visited as it is in clear text every time you say hello to a https website.
 
How about if you pick a provider then click apply that is does the add bit for you?

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).

Also is it possible to add DNS over https to our routers in the future?

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.
 

Latest threads

Sign Up For SNBForums Daily Digest

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