[Release] Asuswrt-Merlin 384.11 is available

[RMerlin]

partially enabled ---- note the gui is back to normal (doesn't show netools anymore) and some portions are functioning as should-- seems to be traceroute so far is the main issue- i can get perfect traceroutes in putty for the RT-AC5300 just not the gui.

No, Netool and GPL traceroute were both still enabled in the RT-AC88U_BASE build profile, meaning it's enabled for these three models.

 

[Swistheater]

No, Netool and GPL traceroute were both still enabled in the RT-AC88U_BASE build profile, meaning it's enabled for these three models.

that explains a lot.

 

[L&LD]

Adding to successful upgrades, I finished updating the RT-AC3100 in addition to the RT-AC86U.

Much more straightforward on this model.

Reboot the router, wait 10 minutes, flash the 384.11_0 release. No need to remove the USB drive with the same scripts installed.

The details on the slightly more involved RT-AC86U is here.

 

[#TY]

Do we need to uninstall Stubby (or any other scripts) prior to updating to .11?

 

[Swistheater]

if you plan on turning on the built in DoT feature then you will have to remove stubby, if you plan on using the built in time server and redirect then you have to uninstall ntpmerlin

 

[jfjm]

Upgraded to .11, DoT works great. Thanks for making all this happen so quickly!

 

[doczenith1]

Adding to successful upgrades, I finished updating the RT-AC3100 in addition to the RT-AC86U.

Much more straightforward on this model.

Reboot the router, wait 10 minutes, flash the 384.11_0 release. No need to remove the USB drive with the same scripts installed.

The details on the slightly more involved RT-AC86U is here.

My 86U went smoothly. I rebooted and let the router settle in for ten minutes and then issued the firmware update. No USB drive removal.

 

[#TY]

- I uninstalled Stubby prior to installing the .11 update.
- I rebooted the router and waited 10 minutes for it to settle.
- I went into the WAN section and set my settings as shown in the attached PDF.
Can anyone please confirm if they are correct or if I need to do something more? (more specifically, do I need to turn on DNS Bind protection and DNSSEC support?

- Lastly, there is a small type in the tooltip help for DNS-over-TLS profile (see attached screenshot). The word authenticate is misspelled

Thanks to all in advance.

 

[RDaneel]

Well... I likely missed it, but saw no statement along the lines of "this is not the same as BETA 2" (or is)... just sayin'.

Much more worrisome than that, I came home to a disabled 2.4 GHz side of my WiFi network!

... which means all the TP-Link WiFi-controlled devices are out of the picture - which means my cats were in the dark (yes, I know cats see better than we do, but still).

This is still me, so that means RT-AX88U, Win 10 Pro x64 with all patches (BTW).

The 3 pieces of "evidence" I see are a) the devices that only function on 2.4 GHz are not happening, b) the main status page on the Web UI view shows a weird "WiFi signal strength" graphic with the LEFT-hand side green and happy, and the RIGHT-hand side all dark, and c) the Wireless page for 2.4GHz shows the Control Channel set to Auto, NO ability to change it, and a displayed current control channel value of ZERO.

So, ol' BETA 2 of ".11" has worked for about 2 days after I used the magic script from Swistheater to restore my ipv6... I am somewhat disinclined to go ahead and "upgrade" to the real ".11" release, but my choices are not attractive in general, I suppose.

Suggestions or questions?

 

[Swistheater]

Well... I likely missed it, but saw no statement along the lines of "this is not the same as BETA 2" (or is)... just sayin'.

Much more worrisome than that, I came home to a disabled 2.4 GHz side of my WiFi network!

... which means all the TP-Link WiFi-controlled devices are out of the picture - which means my cats were in the dark (yes, I know cats see better than we do, but still).

This is still me, so that means RT-AX88U, Win 10 Pro x64 with all patches (BTW).

The 3 pieces of "evidence" I see are a) the devices that only function on 2.4 GHz are not happening, b) the main status page on the Web UI view shows a weird "WiFi signal strength" graphic with the LEFT-hand side green and happy, and the RIGHT-hand side all dark, and c) the Wireless page for 2.4GHz shows the Control Channel set to Auto, NO ability to change it, and a displayed current control channel value of ZERO.

So, ol' BETA 2 of ".11" has worked for about 2 days after I used the magic script from Swistheater to restore my ipv6... I am somewhat disinclined to go ahead and "upgrade" to the real ".11" release, but my choices are not attractive in general, I suppose.

Suggestions or questions?

can you please post a picture of this page

 

[RDaneel]

can you please post a picture of this page
... (graphic above) ...

Well, the bad news is I got annoyed with not being able to control my 2.4 GHz devices (like a number of the key lights in my house), so I did a reboot of the AX88U from the GUI - of course, now things are working once more (including the 2.4 GHz side of things being enabled etc) - but past that, I might mention a number of configurable items differ, so I expect you have altered yours, or you don't have an AX88U(?).

So, I will keep watching, but if anyone is leaning towards just doing the update, on the basis that our benefactor is unlikely to put significant time into the "old" BETA now... just say that (please).

 

[westmc]

I loosely followed the beta thread so I know that people had issues with cloudflare + DNSSEC but I am confused. I just upgraded tonight, enabled DoT (to cloudflare, which I was already using) without issue. When I go to the cloudflare test page with DNSSEC disabled, it tells me that I am verifying DNSSEC. When I actually enable DNSSEC, it still tells me that I am validating but that I am no longer running DoT. People mentioned this as a bug in the beta thread, but also mentioned that DNSSEC should be disabled with cloudflare. What settings should I use? Is DNSSEC with "Validate unsigned DNSSEC replies" worth it? The tooltip for the validate option mentions a performance impact. People in the beta thread also mentioned that most websites don't support DNSSEC.

I should also add that besides the cloudflare test page saying that I am verifying DNSSEC when I have the option disabled, https://dnssec.vs.uni-due.de/ also says I am verifying. How is that working if I have it disabled?

 

[MarkRH]

I loosely followed the beta thread so I know that people had issues with cloudflare + DNSSEC but I am confused. I just upgraded tonight, enabled DoT (to cloudflare, which I was already using) without issue. When I go to the cloudflare test page with DNSSEC disabled, it tells me that I am verifying DNSSEC. When I actually enable DNSSEC, it still tells me that I am validating but that I am no longer running DoT. People mentioned this as a bug in the beta thread, but also mentioned that DNSSEC should be disabled with cloudflare. What settings should I use? Is DNSSEC with "Validate unsigned DNSSEC replies" worth it? The tooltip for the validate option mentions a performance impact. People in the beta thread also mentioned that most websites don't support DNSSEC.

I should also add that besides the cloudflare test page saying that I am verifying DNSSEC when I have the option disabled, https://dnssec.vs.uni-due.de/ also says I am verifying. How is that working if I have it disabled?

The deal is, with DNSSEC disabled in the router GUI, since the Cloudflare DNS resolvers support DNSSEC, both those tests work fine. When you enable DNSSEC in the router GUI, the Cloudflare test page breaks due to some of the test URLs failing the DNSSEC response:

May  9 00:27:19 dnsmasq[239]: Insecure DS reply received for is-cf.cloudflareresolve.com.cdn.cloudflare.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers

It's a problem with Cloudflare's page really and is why it thinks you're not using DoT. The https://dnssec.vs.uni-due.de/ test still works fine though.

 

[westmc]

The deal is, with DNSSEC disabled in the router GUI, since the Cloudflare DNS resolvers support DNSSEC, both those tests work fine.

Does that mean that I don't need to enable DNSSEC if cloudflare is already doing it?

 

[#TY]

Does that mean that I don't need to enable DNSSEC if cloudflare is already doing it?

Correct. With all the others, I believe you would need to enable it but not Cloudflare. This is what I've understood anyhow - please correct me if its inaccurate.

 

[Treadler]

Does that mean that I don't need to enable DNSSEC if cloudflare is already doing it?

No,
Enabling DNSEC in the router GUI ensures DNSSEC validation over the ‘last mile’, ie, between the DNS server & you.
So, Cloudflare (or Google, or Quad9) does DNSSEC=yes: enabling locally means you are verifying locally what you get from Cloudflare (or Google, Quad9) as being still ok, not tampered with, when it gets to you.

 

[westmc]

Enabling DNSEC in the router GUI ensures DNSSEC validation over the ‘last mile’, ie, between the DNS server & you.
So, Cloudflare does DNSSEC=yes, enabling locally means you are verifying locally what you get from Cloudflare as being still ok, not tampered with.

So with DoT enabled, the only way that it could be tampered with is if cloudflare itself got hacked since DoT would prevent a man-in-the-middle attack, right?

 

[Treadler]

So with DoT enabled, the only way that it could be tampered with is if cloudflare itself got hacked since DoT would prevent a man-in-the-middle attack, right?

In theory, DoT stops the bad guys seeing what you’re doing (hence “DNS Privacy”), DNSSEC stops the bad guys altering your stuff, so “Security”.

DNSSEC is the useful one for man in the middle attacks.

DoT & DNSSEC complement each other, with very little overlap in function.

 

[martinr]

In theory, DoT stops the bad guys seeing what you’re doing (hence “DNS Privacy”), DNSSEC stops the bad guys altering your stuff, so “Security”.

DNSSEC is the useful one for man in the middle attacks.

DoT & DNSSEC complement each other, with very little overlap in function.

Prompted by your 2 helpful posts, I found:
“While DNSSEC ensures integrity of data between a resolver and an authoritative server, it does not protect the privacy of the “last mile” towards you. DNS resolver, 1.1.1.1, supports both emerging DNS privacy standards - DNS-over-TLS, and DNS-over-HTTPS, which both provide last mile encryption to keep your DNS queries private and free from tampering.”
at https://blog.cloudflare.com/dns-resolver-1-1-1-1/

 

[Diamond67]

Flashed (dirty) from 384.10_2. No issues so far.

Also, the new Disk check script of amtm 2.0 (or higher) (requires firmware version 384.11 or higher) kicked in. Nice!