[Beta] Asuswrt-Merlin 384.11 Beta is now available

[jsbeddow]

OK, now I am seeing the results that others are as well: it's just odd that the "Secure DNS" test fails on this page

https://www.cloudflare.com/ssl/encrypted-sni/

when the (pure/strict) Enable DNSSEC support settings are enabled in the GUI. When that setting is turned off, I also get the first three green/pass marks on that test, as well as the expected passes on the other CF "help" page test. Now I know that having the GUI setting turned Off is falsely reassuring though, as it bypasses the real security potential of properly implemented strict DNSSEC.

Thanks to all who responded, as well as the seemingly infinite patience of @RMerlin; who by now must be questioning his decision to implement DOT, given the flood of questions it has prompted from so many users like myself.

Edit: BTW, I have seen the technical explanations of why the Cloudflare tests fail: lets hope they are hearing our requests for a better test setup.

 

[L&LD]

Can’t access the GUI after dirty flashing from 384.10_2 on both ac3100 I have.

Was asked to manually reboot.

The router is alive, as I see the ssid specific to the the two ac3100 I am using as Access points. Just no access to the GUI.

All I have to do (since the RT-N66U, if I am recalling correctly) is simply refresh or shut down the browser and open it again.

I think it is just a caching issue.

 

[RMerlin]

I think it is just a caching issue.

No, it was a bug in the kernel that caused some of the files within flash to appear as corrupted. In the AC3100 case, it was probably preventing it from fully booting.

 

[L&LD]

No, it was a bug in the kernel that caused some of the files within flash to appear as corrupted. In the AC3100 case, it was probably preventing it from fully booting.

Maybe I was seeing another issue then? Or else, how would a CTRL F5 reload the login page for me then? I may be wrong on the RT-N66U, that was a long time ago now. But the RT-AC68U, RT-AC3100 and the RT-AC86U all could be 'fixed' by that simple reload of the browser page.

 

[GoNz0]

That site shows I am not using TLS, and I am configured to use Cloudflare DNS-TLS in the router

Same here

Sent from my SM-G920F using Tapatalk

 

[Treadler]

OK, now I am seeing the results that others are as well: it's just odd that the "Secure DNS" test fails on this page

https://www.cloudflare.com/ssl/encrypted-sni/

when the (pure/strict) Enable DNSSEC support settings are enabled in the GUI. When that setting is turned off, I also get the first three green/pass marks on that test, as well as the expected passes on the other CF "help" page test. Now I know that having the GUI setting turned Off is falsely reassuring though, as it bypasses the real security potential of properly implemented strict DNSSEC.

Thanks to all who responded, as well as the seemingly infinite patience of @RMerlin; who by now must be questioning his decision to implement DOT, given the flood of questions it has prompted from so many users like myself.

Edit: BTW, I have seen the technical explanations of why the Cloudflare tests fail: lets hope they are hearing our requests for a better test setup.

I hear you. The CF test page seems to cause less trouble if it’s ignored!
Until someone says different, I’m continuing with DoT & DNSSEC full on.....

Infinite patience of Merlin. Yup, dunno how he does it.
To some extent he is providing fixes/improvements that are way above the pay grade of someone like me. Necessarily gives rise to questions, again, from people like me!

 

[RMerlin]

Maybe I was seeing another issue then? Or else, how would a CTRL F5 reload the login page for me then? I may be wrong on the RT-N66U, that was a long time ago now. But the RT-AC68U, RT-AC3100 and the RT-AC86U all could be 'fixed' by that simple reload of the browser page.

Different issue. Web server most likely failed to start on the initial AC3100 beta1 build due to bogus read errors from flash.

 

[XIII]

Thanks to all who responded, as well as the seemingly infinite patience of @RMerlin; who by now must be questioning his decision to implement DOT, given the flood of questions it has prompted from so many users like myself.

On the other hand that’s also proof that he has once again implemented something that many people really appreciate. So I hope this actually encourages him.

PS: I gave up my custom unbound DoT configuration, since DoT works so well/easy in 384.11.

 

[RMerlin]

Anything else I can try?

Send me your boot log.

I reviewed the code chain, and nothing looks wrong there. The WAN code only starts the OpenVPN instances after WAN comes up. Both the VPN client and server check for ntp_ready to be set, and if it's not set, they wait for up to 5 minutes for it to be set (retrying after increasing wait times). I'm also unable to reproduce the problem here, everything happens in the proper order, and within a normal period of time.

So, either your ISP is taking forever to bring the WAN online, or something else in your configuration is interfering with the boot process.

 

[Joey Crocker]

Well i rescued my ac3100 back to the merlin stable and i can access gui now i see a new beta is up is that version fixed?

 

[goRt]

Hi,
AC86U - I have to use a USB modem (configured as an Android phone) and the new DNS settings do not show in WAN/Internet connection.

Thanks

 

[RMerlin]

I am getting the following error while trying to connect to the router with ssh:

Apr 27 14:27:34 dropbear[2125]: Early exit: Bad buf_getptr

The ssh server on the router is configured for Lan Only, either password or keys. I have performed a full reset after upgrading. Any clues to what's happening here appreciated...

@RMerlin - has this been reported previously or do I have a config problem? Unable to access router via ssh.

Unable to reproduce (and I do connect a lot over SSH with my routers during development). Check your client settings, or try with a different client.

 

[RMerlin]

Well i rescued my ac3100 back to the merlin stable and i can access gui now i see a new beta is up is that version fixed?

Yes, it's mentioned in the first two posts.

 

[FLA_NL]

I'm getting this error:
Apr 28 08:24:50 dnsmasq[4556]: possible DNS-rebind attack detected: 192-168-2-20.<removed token>.plex.direct

This is when I force (DNS Filter) the entire network using DOT with DNSSEC enabled, using CF as DNS provider, and I'm trying to cast from an Android Plex app to Chromecast audio.

When I turn off rebind protection or I configure both the Android client and chromecast to bypass DOT, then it works again.

It doesn't matter if the Plex server is still using DOT or not.

The router is a RT-AC86U.

 

[RMerlin]

I'm getting this error:
Apr 28 08:24:50 dnsmasq[4556]: possible DNS-rebind attack detected: 192-168-2-20.<removed token>.plex.direct

This is how rebind protection works - it will reject public DNS entries with a non-public IP. If you need to use such DNS entries, then you must disable DNS Rebind protection.

Chances are your Plex client usually connects directly to a remote DNS, bypassing your router's rebind protection.

So, working as intended.

 

[FLA_NL]

This is how rebind protection works - it will reject public DNS entries with a non-public IP. If you need to use such DNS entries, then you must disable DNS Rebind protection.

Chances are your Plex client usually connects directly to a remote DNS, bypassing your router's rebind protection.

So, working as intended.

Thanks for clarifying that. The only thing that I'm wondering about is why this didn't happen to me on older firmwares or when bypassing DOT. I always had the rebind protection option enabled.

 

[Joey Crocker]

Yes, it's mentioned in the first two posts.

Ok thanks i just installed it is running fine so far thank you for such a quick fix.

 

[RMerlin]

Thanks for clarifying that. The only thing that I'm wondering about is why this didn't happen to me on older firmwares or when bypassing DOT. I always had the rebind protection option enabled.

Some Android software will use hardcoded DNS servers. The Netflix application for instance is hardcoded for 8.8.8.8. Using DNSFilter causes these to go through the router's dnsmasq instead.

 

[FLA_NL]

Some Android software will use hardcoded DNS servers. The Netflix application for instance is hardcoded for 8.8.8.8. Using DNSFilter causes these to go through the router's dnsmasq instead.

But the method I use to bypass DOT, is by using the DNS Filter and setting those clients to a specific DNS. Or is dnsmasq only being used for DOT in this case?

Also on previous firmwares I always have been using DNS Filter to force clients to use the DNS that I specify. With the global option to for example q9 and Android clients to adguard.

 

[Striker317]

Maybe I was seeing another issue then? Or else, how would a CTRL F5 reload the login page for me then? I may be wrong on the RT-N66U, that was a long time ago now. But the RT-AC68U, RT-AC3100 and the RT-AC86U all could be 'fixed' by that simple reload of the browser page.

Different issue.