[Beta] Asuswrt-Merlin 384.11 Beta is now available

[MDM]

It's because of a missing build time setting (merlinupdate wasn't enabled on these rebuilds).

Ah, I see. So it will get fixed on its own in next build, tnx.

 

[bbunge]

And that's why it's listed as Quad 9 (insecure).

That is why we have been asking for the second Quad9 secure resolver, 149.112.112.112. I see no reason for the Quad9 insecure. Google and Cloudflare are insecure.....

Sent from my SM-T380 using Tapatalk

 

[MDM]

Sorry...the listing was hard to follow...looked like 9.9.9.10 was the secondary address

Is it an error, why does it list as secure (green)?

 

[RMerlin]

Is it an error, why does it list as secure (green)?

View attachment 17291

What Quad9 calls "insecure" simply means it doesn't provide any of the malware filtering capabilities of the regular 9.9.9.9 resolver. It's still using DoT and providing DNSSEC support.

 

[nlurker]

the new beta has the force option too

Thanks for telling me! I look forward to upgrading after the beta testing is finished.

 

[L&LD]

the new beta has the force option too

Thanks for telling me! I look forward to upgrading after the beta testing is finished.

​

No, it doesn't. Only enables an option that most clients will ignore.

ntpMerlin actually makes NTP requests be replied to by the router.

RMerlin's option requires you to configure every client to use the router instead.

 

[RMerlin]

RMerlin's option requires you to configure every client to use the router instead.

He's referring to this option that is added for beta 2:

Sorry for the blown-up screenshot, I guess Greenshot isn't high DPI aware...

 

[Jack Yaz]

He's referring to this option that is added for beta 2:

View attachment 17298

Sorry for the blown-up screenshot, I guess Greenshot isn't high DPI aware...

I suppose I just need to find out if ntpq etc. still works. Does the built-in ntpd support any configuration files?

 

[RMerlin]

I suppose I just need to find out if ntpq etc. still works. Does the built-in ntpd support any configuration files?

Not really, the only thing it supports through a config file is a list of servers. Config options are limited to what is supported by the command line arguments.

 

[Jack Yaz]

Not really, the only thing it supports through a config file is a list of servers. Config options are limited to what is supported by the command line arguments.

Ok, i wasn't sure if it accepted the standard ntp.conf file that is called usually with -c (apologies if this was discussed before, I've been out of the loop for a few days)

 

[DonnyJohnny]

Awesome, thanks for sharing owine! That is the first real confirmation I've seen that it is an actual bug and cloudflare is aware of it.

For those seeking to verify dns security, note merlin's OP where he mentions using tcpdump. Also be aware, with the built in webui secure dns, if you disable dnssec you will only be giving up some additional security/privacy. I see no reason to give up dnssec just so a silly webpage test works, especially when there are more direct ways to test already.

Most important is a dig test to see if you have the ad flag
https://docs.menandmice.com/display/MM/How+to+test+DNSSEC+validation

 

[fearz]

DNSSEC validation is now done by dnsmasq, that's what this post was referring to. Therefore no proxying.



As written in the changelog: 45713 GPL, with 45149 binary blobs:

  - UPDATED: Other models to 384_45713 GPL (RT-AC87U, RT-AC3200 and
             RT-AC5300 still using 384_45149 binary blobs)

Thank you

 

[kernol]

Keep an eye on @RMerlin 's change log.

Thanks - I see @RMerlin's change log has now been updated and corrected to show that the RT-AC5300 is still on the older 384_45149 binary blobs - so clearly Asus has not yet released an update . Sincerely hope Asus does so before final release or Merlin-Ware 384.11 .

 

[Treadler]

Some advice please........

I’m getting a lot of this:

Apr 30 20:00:29 kernel: x7 : 00000000f63ff71c x6 : 00000000000a075e
Apr 30 20:00:29 kernel: x5 : 0000000000000000 x4 : 00000000f63ff6c8
Apr 30 20:00:29 kernel: x3 : 0000000000000000 x2 : 00000000ffa32954
Apr 30 20:00:29 kernel: x1 : 000000000007c66c x0 : 0000000000000000

Every 25 minutes or so.
Does anyone know what it might be?

Except for this appearing in the log, everything appears to be working just fine!

 

[Turb-z]

I've enabled dns over tls and used cloudflares preset severs for ipv4 and ipv6 but on 1.1.1.1/help I get
Connectivity to Resolver IP Addresses
1.1.1.1 Yes
1.0.0.1 Yes
2606:4700:4700::1111 No
2606:4700:4700::1001 No

and looking in log I have no WAN IPv6 Gateway as its now empty. is there a way to fix this?

 

[Treadler]

I've enabled dns over tls and used cloudflares preset severs for ipv4 and ipv6 but on 1.1.1.1/help I get
Connectivity to Resolver IP Addresses
1.1.1.1 Yes
1.0.0.1 Yes
2606:4700:4700::1111 No
2606:4700:4700::1001 No

and looking in log I have no WAN IPv6 Gateway as its now empty. is there a way to fix this?

Puzzling. IPv6 normally works for you?
Reboot router perhaps?

 

[Swistheater]

I've enabled dns over tls and used cloudflares preset severs for ipv4 and ipv6 but on 1.1.1.1/help I get
Connectivity to Resolver IP Addresses
1.1.1.1 Yes
1.0.0.1 Yes
2606:4700:4700::1111 No
2606:4700:4700::1001 No

and looking in log I have no WAN IPv6 Gateway as its now empty. is there a way to fix this?

make sure jffs custom scripts is enabled under administration on the gui

use ssh to make a wan-start script

cat << EOF > /jffs/scripts/wan-start
#
#!/bin/sh
echo "1" > /proc/sys/net/ipv6/conf/all/accept_ra
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
echo "1" > /proc/sys/net/ipv6/conf/eth0/accept_ra
echo "0" > /proc/sys/net/ipv6/conf/eth0/forwarding
EOF

make executable chmod a+rx /jffs/scripts/wan-start

if you already have a wan-start script (check using "ls /jffs/scripts" first)
you can
nano /jffs/scripts/wan-start
and copy and paste
echo "1" > /proc/sys/net/ipv6/conf/all/accept_ra
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
echo "1" > /proc/sys/net/ipv6/conf/eth0/accept_ra
echo "0" > /proc/sys/net/ipv6/conf/eth0/forwarding
to the end of the script

reboot afterwards

 

[Turb-z]

Puzzling. IPv6 normally works for you?
Reboot router perhaps?

forgot to mention router is rt-ax88u and ipv6 was working fine on 384.10. even after rebooting still the same. thanks

 

[Turb-z]

make sure jffs custom scripts is enabled under administration on the gui

use ssh to make a wan-start script

cat << EOF > /jffs/scripts/wan-start
#
#!/bin/sh
echo "1" > /proc/sys/net/ipv6/conf/all/accept_ra
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
echo "1" > /proc/sys/net/ipv6/conf/eth0/accept_ra
echo "0" > /proc/sys/net/ipv6/conf/eth0/forwarding
EOF

make executable chmod a+rx /jffs/scripts/wan-start

if you already have a wan-start script (check using "ls /jffs/scripts" first)
you can
nano /jffs/scripts/wan-start
and copy and paste
echo "1" > /proc/sys/net/ipv6/conf/all/accept_ra
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
echo "1" > /proc/sys/net/ipv6/conf/eth0/accept_ra
echo "0" > /proc/sys/net/ipv6/conf/eth0/forwarding
to the end of the script

reboot afterwards

never used jffs custom scripts before. will look up how and try it thanks

 

[Xentrk]

The part that I struggle to understand is when you choose either “Disabled” or “Strict” option, what should the WAN settings be? More specifically, the “Connect to DNS server automatically”. Should the choice here be “Yes” or “No” (and your DNS servers of choice entered)? And why?


Sent from my iPhone using Tapatalk

In the 384.10 and below versions, "Connect to DNS server automatically" = "Yes" means you will connect to your ISP DNS. Selecting "No" enables the option to specify a DNS provider of your choice in the DNS1 and DNS2 fields.

From what I have concluded by reading thru the 384.11 DoT thread is the ability to select a DoT provider appears on the screen no matter if "Connect to DNS server automatically" is set to "No" or "Yes".