[Release] Asuswrt-Merlin 384.11 is available

[Mutzli]

as of right now with my current setup this is what my test looks like
View attachment 17651

I assume you have 'Validate unsigned DNSSEC replies' set to Yes. Switch it to No and all of the X's will be gone.

 

[MDM]

Known thing mentioned N times already.
Turn off "Validate unsigned DNSSEC replies" (set to No) and you will "pass" rootcanary and Cloudflare tests.
With it on it is stricter (the way it is meant to be), it is the tests that are not configured properly and they fail...

P.S.
@Mutzli was quicker

 

[mbze430]

so that sounds like it isn't the option for you then. what are the settings on your wan dns look like? and your lan dhcp server?

Actually, when I turned off my PIA VPN (OpenVPN Client) on the router, it is working perfectly. With DNSFilter set to Router, it's now filtering all clients via DoT.

There has to be some sort of bug or conflict with the OpenVPN client

@RMerlin Is there any specific settings needs to be modified? It looks like when I have my OpenVPN client running DoT starts to leak it would either use my PIA's DNS or Cloudflare (my preferred DoT resolver)

 

[Swistheater]

I assume you have 'Validate unsigned DNSSEC replies' set to Yes. Switch it to No and all of the X's will be gone.

obviously, it will run just like no dnssec is turned on.

Note about the post that was being replied to---
they do not have either router dnssec or stubby turned on they are using Pihole.

 

[Swistheater]

Known thing mentioned N times already.
Turn off "Validate unsigned DNSSEC replies" (set to No) and you will "pass" rootcanary and Cloudflare tests.
With it on it is stricter (the way it is meant to be), it is the tests that are not configured properly and they fail...

P.S.
@Mutzli was quicker

it would help if that response had anything to do with the GUI dnssec

 

[Swistheater]

Actually, when I turned off my PIA VPN (OpenVPN Client) on the router, it is working perfectly. With DNSFilter set to Router, it's now filtering all clients via DoT.

There has to be some sort of bug or conflict with the OpenVPN client

@RMerlin Is there any specific settings needs to be modified? It looks like when I have my OpenVPN client running DoT starts to leak it would either use my PIA's DNS or Cloudflare (my preferred DoT resolver)

you would have to tell your vpn to not use vpn dns, but your vpn should be using traffic on port 853 anyways if it is set to use DoT.

 

[Swistheater]

Known thing mentioned N times already.
Turn off "Validate unsigned DNSSEC replies" (set to No) and you will "pass" rootcanary and Cloudflare tests.
With it on it is stricter (the way it is meant to be), it is the tests that are not configured properly and they fail...

P.S.
@Mutzli was quicker

BTW a valid modern dnssec validating resolver that supports modern DNSSEC algorithms should pass regardless if it is turned on or not.

 

[rk8531]

Are they still marked as executable?

Note that this is only for scripts in /jffs, it shouldn't affect what's on the USB disk.

Now i can confirm that scripts installed in /jffs are not at all working. The script crashes the moment it is executed.

 

[L&LD]

Hi,

I own an RT-AC68U. When I updated it to 384.11 throughput fell down considerably and the ssh server stopped working. However, the web UI still worked, although it took more than 10 seconds to load every page. The problem does not seem to be the DNS, since I access the web UI by IP, and big downloads to external sites were less than 1MB/s (they usually are > 10MB/s).

In addition, when I pinged it I got this:

64 bytes from 192.168.2.1: icmp_seq=350 ttl=64 time=248.168 ms
64 bytes from 192.168.2.1: icmp_seq=351 ttl=64 time=242.491 ms
64 bytes from 192.168.2.1: icmp_seq=352 ttl=64 time=630.903 ms
64 bytes from 192.168.2.1: icmp_seq=353 ttl=64 time=627.387 ms
64 bytes from 192.168.2.1: icmp_seq=354 ttl=64 time=690.883 ms
64 bytes from 192.168.2.1: icmp_seq=355 ttl=64 time=671.202 ms
64 bytes from 192.168.2.1: icmp_seq=356 ttl=64 time=786.211 ms​

Surprisingly, I started to downgrade back to 384.10 and the last 4 pings before the router stopped responding had the regular latency:

64 bytes from 192.168.2.1: icmp_seq=357 ttl=64 time=0.294 ms
64 bytes from 192.168.2.1: icmp_seq=358 ttl=64 time=0.296 ms
64 bytes from 192.168.2.1: icmp_seq=359 ttl=64 time=0.297 ms
64 bytes from 192.168.2.1: icmp_seq=360 ttl=64 time=0.348 ms​

After the downgrade everything went smoothly. Any idea why 384.11 might be having this issue?

You most likely need to flash the latest firmware and then do a full reset to factory defaults afterward. Followed by a minimal and manual configuration to secure the router and connect to your ISP.

I would recommend following the M&M Config guide and the amtm Step-by-Step guide through the link in my signature below.

 

[MDM]

BTW a valid modern dnssec validating resolver that supports modern DNSSEC algorithms should pass regardless if it is turned on or not.

My point exactly!
That is why I said the tests fail (ie the test pages).

 

[tomsk]

When I run that test, this is my result:

View attachment 17652

I haven’t a clue what it all means but I don’t like the red crosses!

I have DoT enabled and it does pass the other tests I use.

Im getting the same result here ... DOT enabled (strict mode) on cloudflare servers, DNSSEC enabled and validate unsigned replies.

Im assuming that for the stock 384.11 that the DNSSEC part is still being handled by Dnsmasq and the DOT part is being handled by stubby. in that sense changing the GUI settings for DNSSEC is making changes to the dnsmasq config?

 

[Swistheater]

Im getting the same result here ... DOT enabled (strict mode) on cloudflare servers, DNSSEC enabled and validate unsigned replies.

Im assuming that for the stock 384.11 that the DNSSEC part is still being handled by Dnsmasq and the DOT part is being handled by stubby. in that sense changing the GUI settings for DNSSEC is making changes to the dnsmasq config?

correct dnssec settings add dnssec option plus the keys to dnsmasq.conf.

 

[Wayne Hutchinson]

Asus just released a new firmware correcting a number of things.


Version 3.0.0.4.384.457172019/05/1341.41 MBytes

ASUS RT-AC5300 Firmware version 3.0.0.4.384.45717
Security Fix
- Fixed DDoS vulnerability.
- Fixed AiCloud vulnerability. Thanks for Matt Cundari's contribution.
- Fixed command injection vulnerability. Thanks for S1mba Lu's contribution.
- Fixed buffer overflow vulnerability. Thanks for Javier Aguinaga's contribution.
- Fixed CVE-2018-20334
- Fixed CVE-2018-20336
- Fixed null pointer issue. Thanks for CodeBreaker of STARLabs’ contribution.
- Fixed AiCloud buffer overflow vulnerability. Thanks for Resecurity International's contribution.

Bug Fix
- Fixed AiMesh LAN IP issue when router using IPv6 WAN.
- Fixed AIMesh connection issues.
- Fixed Network Map related issues.
- Fixed Download Master icon disappear issue.
- Fixed LAN PC cannot find router name in My Network Places when enabling Samba service.
- Fixed LAN LED not blinking problem.

Please unzip the firmware file first then check the MD5 code.
MD5: 232487a51126099c96eeee8ed67c0dc0

 

[Gar]

Stubby in 384.11 uses what is called round robin. This uses each resolver entry in turn then back to the first. So it cycles through all entries. This is supposed to improve response and in earlier Stubby versions was recommended to prevent errors due to a bug.

Sent from my SM-T380 using Tapatalk

Is using 2 different resolvers a better choice than both from same? I.e., q9&q1 as dns1&2 vs q9&149.xxx?

 

[Swistheater]

Asus just released a new firmware correcting a number of things.


Version 3.0.0.4.384.457172019/05/1341.41 MBytes

ASUS RT-AC5300 Firmware version 3.0.0.4.384.45717
Security Fix
- Fixed DDoS vulnerability.
- Fixed AiCloud vulnerability. Thanks for Matt Cundari's contribution.
- Fixed command injection vulnerability. Thanks for S1mba Lu's contribution.
- Fixed buffer overflow vulnerability. Thanks for Javier Aguinaga's contribution.
- Fixed CVE-2018-20334
- Fixed CVE-2018-20336
- Fixed null pointer issue. Thanks for CodeBreaker of STARLabs’ contribution.
- Fixed AiCloud buffer overflow vulnerability. Thanks for Resecurity International's contribution.

Bug Fix
- Fixed AiMesh LAN IP issue when router using IPv6 WAN.
- Fixed AIMesh connection issues.
- Fixed Network Map related issues.
- Fixed Download Master icon disappear issue.
- Fixed LAN PC cannot find router name in My Network Places when enabling Samba service.
- Fixed LAN LED not blinking problem.

Please unzip the firmware file first then check the MD5 code.
MD5: 232487a51126099c96eeee8ed67c0dc0

that is not the GPL release

 

[Wayne Hutchinson]

Oh, OK
Would think that would follow, would it not?

 

[Swistheater]

Im getting the same result here ... DOT enabled (strict mode) on cloudflare servers, DNSSEC enabled and validate unsigned replies.

Im assuming that for the stock 384.11 that the DNSSEC part is still being handled by Dnsmasq and the DOT part is being handled by stubby. in that sense changing the GUI settings for DNSSEC is making changes to the dnsmasq config?

This is an example of test run and type of results that may show.

 

[jsbeddow]

Oh, OK
Would think that would follow, would it not?

Yes, of course the GPL will eventually follow, but it is up to Asus on when. There is no need to ever post these announcements in this part of the forum: RMerlin is always aware of the new releases (usually before the general public), and the announcements of new firmware releases always come up fast over in the "Official" AsusWRT side of the forum.

 

[jsbeddow]

This is an example of test run and type of results that may show.
View attachment 17654
View attachment 17655

Thank you, really helpful to see all the possible scenarios laid out with proper labeling. Great work.

 

[DAVIZINHO]

I am new here (spanish too) Movistar IPTV dónt charge the channels with the lats firmware 384.11 Please can you aid us? Thanks you for your great job. (sorry, and i will donate by Paypal)

some messages before confirm the problem with some models. in the new 384.11_2 it will be solved.
we must waint until release or go back to 384.11 beta2