Beta Asuswrt-Merlin 3004.388.6_x test builds (dnsmasq 2.90)

[DJones]

Try disabling logging for Diversion if you use it. Only time I’ve experienced sluggishness from my router is when that’s enabled. Unfortunately DoH really isn’t anything to do with Asuswrt-Merlin besides the option to “Prevent client auto DoH” so from a troubleshooting perspective you’re going to need process of elimination. I use DoT, and ensure the secondary server is cloudflare and the non DoT DNS is set to cloudflares 1.1.1.1 etc to avoid my isps DNS from being used as a fallback, and set DNS Director to Router. I block hardcoded dns like googles 8.8.8.8 to avoid dns leaks. DNS wise DoT works great, but I disabled DoH on my browsers in theory it should work with DoH as well, but then I would possibly cause issue with QoS cake, ad blocking and skynet blacklists. But can’t say that’s would happen for sure.

 

[Damit1]

If your browsers have DoH enabled then you are by-passing the router DNS.

Nope, didn't configured them "manually".

 

[bbunge]

Nope, didn't configured them "manually".

You stated "I m using CloudFlare and Google, DoT and DoH enabled"
Since the router does not use DoH your browsers do.

 

[Damit1]

You stated "I m using CloudFlare and Google, DoT and DoH enabled"
Since the router does not use DoH your browsers do.

Already confused, LOL.
DoH is not enabled, DNSSEC and DoT do.

 

[bbunge]

Try disabling logging for Diversion if you use it. Only time I’ve experienced sluggishness from my router is when that’s enabled. Unfortunately DoH really isn’t anything to do with Asuswrt-Merlin besides the option to “Prevent client auto DoH” so from a troubleshooting perspective you’re going to need process of elimination. I use DoT, and ensure the secondary server is cloudflare and the non DoT DNS is set to cloudflares 1.1.1.1 etc to avoid my isps DNS from being used as a fallback, and set DNS Director to Router. I block hardcoded dns like googles 8.8.8.8 to avoid dns leaks. DNS wise DoT works great, but I disabled DoH on my browsers in theory it should work with DoH as well, but then I would possibly cause issue with QoS cake, ad blocking and skynet blacklists. But can’t say that’s would happen for sure.

Diversion 5.1 running with logging enabled. No problems. DNS Director enabled for router.

 

[DJones]

Diversion 5.1 running with logging enabled. No problems. DNS Director enabled for router.

I haven’t tested logging since Diversion was rewritten in version 5.0 so my experience may be outdated. I also used the standard pixelserv version with a USB stick for entware, which is likely the case for a lot of people even though it’s far from optimal. So in terms of async speed reading/writing too and from it isn’t going to be great quite literally a bottleneck, but it works, and nothing crazy is used on the router so till the stick dies is what it is.

 

[cc666]

Installed and working perfectly. Passed the test

https://www.internetsociety.org/resources/deploy360/2011/testing-dnssec-analyzer/

It fails here if you put in google.com as the url to check on top

DNSSEC Debugger - www.google.com

The DNSSEC Debugger from VeriSign Labs is an on-line tool to assist with diagnosing problems with DNSSEC-signed names and zones.

dnssec-debugger.verisignlabs.com

Merlin can you look at these tests.

CC

 

[RMerlin]

All this says is that google.com isn`t DNSSEC signed. You will have to ask Google to sign it...

This site tests the domain name, not your DNS resolver.

 

[Mogsy]

Which is also vulnerable until Entware can publish v1.19.1.

v1.19.0-2 is available through amtm ep

 These Entware updates are available:
 - procps-ng-pkill - 3.3.16-3a - 4.0.4-1
 - terminfo - 6.4-2 - 6.4-2a
 - column - 2.39-2 - 2.39.3-1
 - zoneinfo-europe - 2023c-2 - 2024a-1
 - jq - 1.6-2 - 1.7.1-1
 - unbound-checkconf - 1.17.1-1 - 1.19.0-2
 - unbound-daemon - 1.17.1-1 - 1.19.0-2
 - libnghttp2 - 1.51.0-1 - 1.57.0-1
 - grep - 3.8-2 - 3.11-1
 - zoneinfo-asia - 2023c-2 - 2024a-1
 - unbound-control - 1.17.1-1 - 1.19.0-2
 - libgnutls - 3.8.0-3 - 3.8.3-1
 - nmap - 7.93-2 - 7.93-4
 - libunbound - 1.17.1-1 - 1.19.0-2
 - chrony-nts - 4.4-1 - 4.5-1
 - zoneinfo-core - 2023c-2 - 2024a-1
 - libsmartcols - 2.39-2 - 2.39.3-1
 - bind-libs - 9.18.16-1 - 9.18.19-1
 - entware-release - 1.0-2 - 2024.02-1
 - libncurses - 6.4-2 - 6.4-2a
 - libuv - 1.45.0-1 - 1.45.0-3
 - libopenssl-conf - 3.0.10-1 - 3.0.13-1
 - zlib - 1.2.13-1 - 1.3.1-1
 - libncursesw - 6.4-2 - 6.4-2a
 - htop - 3.2.2-1 - 3.3.0-1
 - procps-ng - 3.3.16-3a - 4.0.4-1
 - bind-dig - 9.18.16-1 - 9.18.19-1
 - libgmp - 6.2.1-1a - 6.3.0-1
 - unbound-anchor - 1.17.1-1 - 1.19.0-2
 - libopenssl - 3.0.10-1 - 3.0.13-1
 - libedit - 20221030-3.1-1 - 20230828-3.1-1

 

[dave14305]

v1.19.0-2 is available through amtm ep

That’s unfortunate. If they don’t update the package individually, you would need to wait another few months for the next Entware update.

 

[MDM]

All works and seems well for me.

 

[Damit1]

Any ETA for stable release?
@RMerlin

Thanks, once again, for all of your hard work.

 

[Analog-1]

Any ETA for stable release?
@RMerlin

Thanks, once again, for all of your hard work.

I would have thought it would already be released as the issue has been fixed. Who knows.

 

[Damit1]

I would have thought it would already be released as the issue has been fixed. Who knows.

Me too, but no pressure.
I'm letting him to take the time, after all- it is done voluntarily...

 

[L&LD]

As far as I'm concerned, this is a stable release.

 

[RMerlin]

Any ETA for stable release?

When I'm satisfied that dnsmasq itself is stable. Since the initial bug fix, the author already issued two additional fixes for issues that he introduced with the 2.90 release. So I won't issue a firmware release until dnsmasq had gone a few days without any further bugfixes.

 

[Damit1]

When I'm satisfied that dnsmasq itself is stable. Since the initial bug fix, the author already issued two additional fixes for issues that he introduced with the 2.90 release. So I won't issue a firmware rlease until dnsmasq had gone a few days without any further bugfixes.

Oh good!
Hopefully you can issue another "beta" release with the current latest version.

 

[aex.perez]

That moment when the trouble you've been trying to chase down with the release with dnsmasq 2.90 in this firmware. The random performance ones, and the partial page/site loads. Where you have, to an extent, correlated it to a restart of dnsmasq log that you've seen in the log that happened at the same time the problems happen. But you could never capture it, because it would seemingly happen randomly, and only for a short time, and occur on random devices.

When all of a sudden you remember that scMerlin lets you restart dnsmasq easily, with the click of a mouse, on demand

The issues I was reporting with dnsmasq. That I was starting to tie to the restart of it. That manifested when going to a site/page that partially loads, or seemed slow post the restart. Well, the perfermance eventually returns, and pages/sites now load load fine as dnsmasq settles down from the reload (hence randomness ant the short duration of the issues).
Even the first time a page/site is accessed after a reload, or a random page/site is loaded for the first time, no longer happens and performance returns after dnsmasq and router settles down from the reload.

Firefox set to use DoH/DNSSEC with Cloudflare never saw the problems. All browsers (Chrome, Edge, Firefox, Safari, an so on) tested did, regardless of device, DOT configured on the router or not, with WAN DNS set to Cloudflare/Google/others did, on every dnsmaq restart until the router settled down from the reload of dnsmasq.

I can't capture the details in the system log, it doesn't show up. Didn't really didn't see it in TOP/HTOP either.
But I can replicate the effect on demand, hopefully others can and will be able to as well.

Once dnsmasq is running, if a reload isn't triggered again, and the router stays up and running, after things settle down. Performance returns, lookups succeed, pages/sites load fine.

The problems have gone away haven't resurfaced (but haven't had a random event causing dnsmasq restart either)
Hopefully the fixes @RMerlin talks about in post #96 and others running this release of firmware, don't report any other related issues, to get us to another release soon.

 

[cc666]

Now getting thus repeating in my log, any ideas what this means?

Feb 26 00:57:04 kernel: GET STA INFO failed, -21
Feb 26 01:02:06 kernel: GET STA INFO failed, -21
Feb 26 01:07:24 kernel: GET STA INFO failed, -21

CC

 

[RMerlin]

Now getting thus repeating in my log, any ideas what this means?

Feb 26 00:57:04 kernel: GET STA INFO failed, -21
Feb 26 01:02:06 kernel: GET STA INFO failed, -21
Feb 26 01:07:24 kernel: GET STA INFO failed, -21

Wifi related, nothing to do with dnsmasq.