[Beta] Asuswrt-Merlin 384.11 Beta is now available

[Vexira]

Hmmm, I set a static on the device settings and for good measure the Mac binding on router. Possible they conflicting now with new firmware? [emoji848]


Sent from my iPhone using Tapatalk

It is possible

 

[dave14305]

Hmmm, I set a static on the device settings and for good measure the Mac binding on router. Possible they conflicting now with new firmware? [emoji848]


Sent from my iPhone using Tapatalk

If the device IP is set statically, it probably isn’t going to query DHCP at all.

 

[bbunge]

I have reported before that I'm not exactly pleased with the way DoT via Stubby is set up(port and loopback IP address used). Not that it is wrong but it is not the way Stubby was recommended for unbound and the way we tested with the Entware installer script. I feel that something other than port 53 should be used between dnsmasq and stubby. IPV6 listen address should also be in stubby.yml/dnsmasq.

Also noted that when Quad9 was used for DoT Stubby connected to a data center on the west coast of US. Cloudflare connected to a data center about 100 miles away and CleanBrowsing went about 150 miles. Was wondering if there was an issue with the way Merlin had stubby configured. So I took the time to go back to 384.10_2 and installed Entware/Stubby. Did the same "tests" to the same resolvers and pretty much got the same results as with 384.11 B1. Repeating the same tests with DoT off and the resolvers in DNS Server 1 and 2 returned faster results and closer data centers!

This got me wondering if ISP's are messing with anycast IP addresses? Using "normal" DNS via port 53 works as it always has worked for me. Using DoT over port 853 seems to throw a wrench in the works for some resolvers. I realize that encryption may slightly increase DNS lag. But should querries be sent past a half dozen datacenters to one 2,700 miles away?

Thought I would lay these things out for discussion.

 

[Swistheater]

I have reported before that I'm not exactly pleased with the way DoT via Stubby is set up(port and loopback IP address used). Not that it is wrong but it is not the way Stubby was recommended for unbound and the way we tested with the Entware installer script. I feel that something other than port 53 should be used between dnsmasq and stubby. IPV6 listen address should also be in stubby.yml/dnsmasq.

Also noted that when Quad9 was used for DoT Stubby connected to a data center on the west coast of US. Cloudflare connected to a data center about 100 miles away and CleanBrowsing went about 150 miles. Was wondering if there was an issue with the way Merlin had stubby configured. So I took the time to go back to 384.10_2 and installed Entware/Stubby. Did the same "tests" to the same resolvers and pretty much got the same results as with 384.11 B1. Repeating the same tests with DoT off and the resolvers in DNS Server 1 and 2 returned faster results and closer data centers!

This got me wondering if ISP's are messing with anycast IP addresses? Using "normal" DNS via port 53 works as it always has worked for me. Using DoT over port 853 seems to throw a wrench in the works for some resolvers. I realize that encryption may slightly increase DNS lag. But should querries be sent past a half dozen datacenters to one 2,700 miles away?

Thought I would lay these things out for discussion.

I noticed alot of improvements with beta1b once i changed the DNS1 and DNS2 from automatic (using my isp dns) to like say for example cloudflare. I know this isn't ideal for initial connections because it isn't main ISP, but i feel like it take less control away from the ISP as far as the possibilities of them redirecting traffic.

*reboots seem to be alot cleaner as well. also, note i am still connecting to the same servers as i was using the stubby on entware.

 

[Swistheater]

The only issues I am noticing is DNSMAQ DNSSEC vs. STUBBY DNSSEC - I see alot more server fails on good dnssec checks with dnsmasq dnssec v.s. stubby dnssec (seems to load alot cleaner without any issues as far a verifying and validation).
Another issue I have noticed is a lot of errors when testing with ipleak.net

 

[L&LD]

I've been away for months - lost engagement when Merlin firmware for my 56U stopped. Now have finally ordered a 86U. Not opening the box untill 384.11 lands which it might before my 86U arrives

Take it out of the box and test it thoroughly before your return warranty expires.

Even without RMerlin firmware installed on it.

 

[RMerlin]

I feel that something other than port 53 should be used between dnsmasq and stubby

There's no reason to do so. Stubby listens to a loopback interface, so it won't clash with anything else. It's just an arbitrary port chosen between dnsmasq and Stubby. And as an added bonus, it means anything running locally on the router could also use Stubby as a resolver, so using port 53 only adds in potential flexibility.

And from a purist point of view, if you follow IANA's service port listing, port 53 is the proper port to use, since Stubby is receiving a DNS query fron dnsmasq. Port 853 is intended for receiving a TLS-secured DoT query - that is NOT what dnsmasq is sending Stubby at that time. So from a technical point of view, port 53 is the correct port to use here.

IPV6 listen address should also be in stubby.yml/dnsmasq.

Again, no reason to. Stubby gets accessed by dnsmasq on whichever IP it has configured for its own resolver. Using an IPv4 loopback does the same thing, and it's less wasteful of resources than adding an extra interface "just because".

This got me wondering if ISP's are messing with anycast IP addresses? Using "normal" DNS via port 53 works as it always has worked for me. Using DoT over port 853 seems to throw a wrench in the works for some resolvers. I realize that encryption may slightly increase DNS lag. But should querries be sent past a half dozen datacenters to one 2,700 miles away?

Only thing I can think of that could explain such a change is if you get an IP from a different subnet from your ISP after the reboot, and that subnet isn't routed the same way as the previous one.

 

[RMerlin]

The only issues I am noticing is DNSMAQ DNSSEC vs. STUBBY DNSSEC - I see alot more server fails on good dnssec checks with dnsmasq dnssec v.s. stubby dnssec (seems to load alot cleaner without any issues as far a verifying and validation).

Probably dnsmasq being stricter, as by default it will reject unsigned replies coming from a signed zone. Which is basically DNSSEC doing what it's supposed to do.

 

[Swistheater]

Probably dnsmasq being stricter, as by default it will reject unsigned replies coming from a signed zone. Which is basically DNSSEC doing what it's supposed to do.

The issues I am seeing is actually from dnssec not properly resolving signed zones v.s. Simply refusing to resolve an invalid signed zone. I can turn off DoT with the same dnsmasq dnssec parameters and it will resolve no problem.

 

[RMerlin]

The issues I am seeing is actually from dnssec not properly resolving signed zones v.s. Simply refusing to resolve an invalid signed zone. I can turn off DoT with the same dnsmasq dnssec parameters and it will resolve no problem.

I know in the past people mentionned having odd DNSSEC-related issues when using 1.1.1.1 (either with DoT or as native DNS servers). Might be worth trying with Google's Quad8 just to compare.

 

[Swistheater]

I know in the past people mentionned having odd DNSSEC-related issues when using 1.1.1.1 (either with DoT or as native DNS servers). Might be worth trying with Google's Quad8 just to compare.

Sounds worth a try.

 

[RMerlin]

"View List" for clients on the Network Map page always displays zero now for me. I understand this is an ASUS issue, but it at least used to be inconsistent. Now it's consistently zero. FYI. (Beta1b)

Works for me.

 

[Swistheater]

Works for me.

Mine works better than in previous builds. Only items I have issues with are those that are notorious to be oblivious to network map. Every now and then I may have to hit refresh but not like I use to on other builds.

 

[Gar]

Ref Quad8:

Do we trust them with our privacy? Routing everything through them? I suppose they're all watching, but maybe KGB.com has DoT? At least we know what they're up to.

 

[John Adler]

from my laptop I only see the 2.4ghz band...
waht happened to the 5ghz?

 

[chris2kari]

I've never been even slightly tempted to use beta firmware on a router ever before but "DNS-over-TLS support" was just too good to pass up trying.
Applied 384.11 beta 1b to an RT-AC68U. Works! Yay!

Notes:

• The Adguard TLS server is disappointingly very unreliable & slow from my location in New Zealand. (Unencrypted Adguard DNS is reasonably fast so I guess the problem lays with them)

• Quad9, Cloudflare & Neustar/Neutopia are very fast and reliable. I used the dnsperftool (https://github.com/cleanbrowsing/dnsperftest) to check DNS server speeds from my location & good old fashioned dig.
  
• Neustar/Neutopia the best for me. (I prefer to send the queries over port 443 to mix them in with all the other traffic. Seems a little faster also.)

Massive thanks to Merlin for implementing this.

 

[Frankflash]

I've never been even slightly tempted to use beta firmware on a router ever before but "DNS-over-TLS support" was just too good to pass up trying.
Applied 384.11 beta 1b to an RT-AC68U. Works! Yay!

Notes:

• The Adguard TLS server is disappointingly very unreliable & slow from my location in New Zealand. (Unencrypted Adguard DNS is reasonably fast so I guess the problem lays with them)

• Quad9, Cloudflare & Neustar/Neutopia are very fast and reliable. I used the dnsperftool (https://github.com/cleanbrowsing/dnsperftest) to check DNS server speeds from my location & good old fashioned dig.
  
• Neustar/Neutopia the best for me. (I prefer to send the queries over port 443 to mix them in with all the other traffic. Seems a little faster also.)

Massive thanks to Merlin for implementing this.

I am from NewZealand as well

 

[chris2kari]

I am from NewZealand as well

Kia-ora Frank
Using Skinny over a 1Gps fiber line. It cops a flogging from my family & holds up well but thinking of switching to Voyager for the static IP. Any experience to share?

Cheers
Chris

 

[Frankflash]

hi chris

my name is Craig

I use Spark fiber cant you get a Static ip with Skinny

 

[chris2kari]

hi chris

my name is Craig

I use Spark fiber cant you get a Static ip with Skinny

Nope, my mistake not checking on that when I signed on with Skinny...
I note that Spark are now offering Netflix Standard (HD) subscription included at no extra cost in their price for the life of your contract. (We already have a Netflix Premium sub in our household).
I was leaning to Voyager as we may be needing to use their VPS services etc.