[Beta] Asuswrt-Merlin 384.6 beta is now available

[tyreman]

Working good here
pretty plain system
nothing fancy enabled

 

[octopus]

My DNS rebind attack dissapear when I turned on dns-rebind-attack.

Jul 19 19:49:52 dnsmasq[8307]: possible DNS-rebind attack detected: 0gyenb54-8f50f723f7eb8191df68b12afdc910a3db6ad156-mob.d.aa.online-metrix.net

 

[johnathonm]

I probably compiled it for ARM 2.6.26 devices. Someone would need to recompile it against the HND SDK and its 4.1.xx kernel probably.

Thanks Merlin, I was being nosy and saw it

 

[sativa]

All ok here on AC3200 - does this fix the 2.4Ghz issue?

 

[kfp]

All ok here on AC3200 - does this fix the 2.4Ghz issue?

Do you have an issue with 2.4Ghz?

 

[Speedluvver]

Do you have an issue with 2.4Ghz?

Not sure if I do... my ring doorbell is showing connected, but notifications are delayed to chime and my phone.. not sure if it’s router or not but started with this beta...


Sent from my iPad using Tapatalk

 

[bobiii]

Running great on my RT5300. Uptime is 3 days 4 hours 32 minute(s) 51 seconds. Currently 49 clients attached with 2.4 and 5 ghz working great!

 

[INeedYou]

But only this error occurs in this version (384.6 beta 1) in the version 384.5 works without problems.

The ad flag in the response confirms that the query was authenticated by DNSSEC. Therefore I have working DNSSEC validation on my LAN without any error message in my log. Makes me suspect that Cloudflare is the one that's broken, might be possibly due to their lack of proper support for EDNS. Dnsmasq DNSSEC validation is stricter than previous versions, so broken upstream servers might no longer work as before. You can work around this by disabling strict mode through dnsmasq.conf.add, however you will be giving up a portion of the added security DNSSEC is intended to provide you.

So if you want REALLY working DNSSEC support, you need to use an upstream nameserver that properly supports it. Cloudflare does not.

I can confirm that DNSSEC is broken in version 384.6 b1, but it works as it should in version 384.5 and in Fork version 374.43 LTS releases (V33E7)

Maybe DNS rebind protection or dnsmasq test version broken DNSSEC.

Same here:

I have a connection from the ISP and the IP/status blinks - AC68U.

The same thing happens to me (I make factory reset and I do not use backup)


I will wait for the final version for test again.

 

[Theliel]

RT-AC56u here, all working perfectly, DNSSEC too without any problem

DNS rebind protection seem to work fine too

Thank Erik,

 

[RMerlin]

I can confirm that DNSSEC is broken in version 384.6 b1, but it works as it should in version 384.5 and in Fork version 374.43 LTS releases (V33E7)

Maybe DNS rebind protection or dnsmasq test version broken DNSSEC.



The same thing happens to me (I make factory reset and I do not use backup)


I will wait for the final version for test again.

What investigation have you done to confirm it's dnsmasq that's broken and not your upstream server? It's working fine for me. Reread what I wrote about dnsmasq now enforcing proper zone validation.

Sent from my P027 using Tapatalk

 

[Geraner]

Since upgrading to 384.6 b1, I see in my DNS server (Raspberry Pi with Pi-Hole) a lot of DNS requests going from the router to the following two addresses:

aae-spweb-vx.asuscloud.com
aae-sgweb001-1.asuscomm.com

Request are been sent about every 15 seconds.
This has not been in 384.5 and I don't have any Asus cloud services activated in the router.

 

[rtn66uftw]

I use to be that way originally, now I reverted to updating firmware via Ethernet. I can agree with Marin on the wireless issue. While most of the time the update went smooth, every now and then over wireless, the firmware update process would never move past "applying updates, please wait..." But never went to the progress bar, and required rebooting the router

One day experimenting with this issue, I decided to wait 20mins, still said "applying updates, please wait..." And rebooted to see if the router would brick or become corrupt. To my surprise it did update the firmware, the UI for the firmware however never changed or indicated installation.

On wired the only weirdness I experienced is Firefox lags way behind on the router progress bar. Such as the update could be finished, but Firefox will still be at like 60% until you refresh. Chrome so far doesn't lag like Firefox.

Anyways, just wanted to throw in my 2 cent on why I agreed with firmware upgrades over wired

Sent from my LG-H830 using Tapatalk

I have upgraded firmwares over wireless countless times for all 4 routers I own without any problem. I don't think it matters updating via wireless or ethernet. From my understanding, the firmware update process only starts after successful uploading the file from the computer to the router. At that point, what is displayed on your browser is purely for demonstration only as your computer will lose connection to the router anyway

 

[Geraner]

Since upgrading to 384.6 b1, I see in my DNS server (Raspberry Pi with Pi-Hole) a lot of DNS requests going from the router to the following two addresses:

Request are been sent about every 15 seconds.
This has not been in 384.5 and I don't have any Asus cloud services activated in the router.

As soon as I'm withdrawing the ASUS privacy agreement, the DNS requests stopped.
Is ASUS sending data every 15 seconds to their servers??

 

[BuTTuS]

What agreement is that?

 

[skeal]

What agreement is that?

You can find it here. QOS and other stuff will stop working though.

 

[RMerlin]

This is how you actually test DNSSEC...

Jul 22 23:17:29 dnsmasq[30275]: query[A] www.cloudflare.com from 192.168.10.106
Jul 22 23:17:29 dnsmasq[30275]: forwarded www.cloudflare.com to 1.1.1.1
Jul 22 23:17:29 dnsmasq[30275]: dnssec-query[DS] cloudflare.com to 1.1.1.1
Jul 22 23:17:29 dnsmasq[30275]: reply cloudflare.com is DS keytag 2371, algo 13, digest 2
Jul 22 23:17:29 dnsmasq[30275]: dnssec-query[DNSKEY] cloudflare.com to 1.1.1.1
Jul 22 23:17:29 dnsmasq[30275]: reply cloudflare.com is DNSKEY keytag 35273, algo 13
Jul 22 23:17:29 dnsmasq[30275]: reply cloudflare.com is DNSKEY keytag 2371, algo 13
Jul 22 23:17:29 dnsmasq[30275]: validation result is SECURE
Jul 22 23:17:29 dnsmasq[30275]: reply www.cloudflare.com is 198.41.214.162
Jul 22 23:17:29 dnsmasq[30275]: reply www.cloudflare.com is 198.41.215.162

Jul 22 23:18:02 dnsmasq[30275]: query[A] time.nrc.ca from 192.168.10.254
Jul 22 23:18:02 dnsmasq[30275]: forwarded time.nrc.ca to 1.1.1.1
Jul 22 23:18:02 dnsmasq[30275]: dnssec-query[DS] ca to 1.1.1.1
Jul 22 23:18:02 dnsmasq[30275]: reply ca is DS keytag 2134, algo 8, digest 2
Jul 22 23:18:02 dnsmasq[30275]: dnssec-query[DS] nrc.ca to 1.1.1.1
Jul 22 23:18:02 dnsmasq[30275]: dnssec-query[DNSKEY] ca to 1.1.1.1
Jul 22 23:18:02 dnsmasq[30275]: reply ca is DNSKEY keytag 35433, algo 8
Jul 22 23:18:02 dnsmasq[30275]: reply ca is DNSKEY keytag 2134, algo 8
Jul 22 23:18:02 dnsmasq[30275]: reply nrc.ca is no DS
Jul 22 23:18:02 dnsmasq[30275]: validation result is INSECURE
Jul 22 23:18:02 dnsmasq[30275]: reply time.nrc.ca is 132.246.11.229
Jul 22 23:18:02 dnsmasq[30275]: reply time.nrc.ca is 132.246.11.238
Jul 22 23:18:02 dnsmasq[30275]: reply time.nrc.ca is 132.246.11.227

Looks fine here, even when using 1.1.1.1 as the upstream server. I suspect the log entries you are seeing simply indicate a misconfigured domain has an incorrect or missing DS record, which dnsmasq logs. Once again, probably happening now because dnsmasq now defaults to enforced validation. Not a bug, in fact it's DNSSEC working properly for the first time, otherwise in the past a domain hijack could occur without dnsmasq properly detecting ith.

If you want to properly troubleshoot this, you need to enable query logging like I did and look at the actual query itself. You cannot just blindly state "dnssec is now broken" without actually debugging the actual queries...

 

[RMerlin]

Same here:

I have a connection from the ISP and the IP/status blinks - AC68U.

This looks like a page that failed to properly load, or which got loaded while the router was still booting. Notice the "initializing..." and "connecting..." entries in the top header. Flush your browser cache, also check your browser console for any Javascript error.

 

[elintseeker]

This looks like a page that failed to properly load, or which got loaded while the router was still booting. Notice the "initializing..." and "connecting..." entries in the top header. Flush your browser cache, also check your browser console for any Javascript error.

The "initializing..." and "connecting..." in the SSID are my actual SSID names. Sorry for the confusion.

There are no errors in the console in any of the machines and I've cleared the browser cache. When the UI first loads, I'm seeing my "Check internet connection" status and my WAN IP for a second and gets replaced by the disconnected status.

 

[EVO2point0]

Been running on this firmware for the last couple of days without any issue. (RT-AC88U).

 

[JohnSmith]

Upgraded to Beta 1 on my AC3100 and no issues so far.