[Beta] Asuswrt-Merlin 384.11 Beta is now available

[Swistheater]

Yes native ipv6 feature is enabled

Okay log back into putty and type in cat /proc/sys/net/ipv6/conf/eth0/accept_ra

All one line and report back what response it says

 

[Swistheater]

permission denied

Okay try
Ls /jffs/scripts

 

[Swistheater]

I ment ls lower case

 

[Swistheater]

With /proc/sys/net/ipv6/conf/eth0/accept_ra permission denied with cat /proc/sys/net/ipv6/conf/eth0/accept_ra I get 1

You should be getting ipv6 if you got a 1 back

 

[Swistheater]

What type of internet do you have?

 

[Swistheater]

It seems like asus might have broke something else down the line in the firmware if those commands didnt fix your connection. Can you make a screenshot of your ipv6 log page under system logs and tell me if you see a wan ipv6 gateway address?

 

[Swistheater]

Try disabling the release prefix option on the ipv6 web page

 

[dvohwinkel]

Had an issue tonight where my network wouldn't resolve www.youtube.com . RT-AC86U running 384.11 Beta2. I had DoT on with the two cloudfare servers (1.1.1.1 and 1.0.0.1).. with DNSSEC to yes and "Validate unsigned DNSSEC replies" to yes. This setup worked fine for about 4 hours. Then I tried to get to youtube and found it wouldn't resolve. When I set "Validate unsigned DNSSEC replies" to no it worked again. I can get it to fail again by just setting "Validate unsigned DNSSEC replies" back to yes.

thoughts?

 

[Swistheater]

Had an issue tonight where my network wouldn't resolve www.youtube.com . RT-AC86U running 384.11 Beta2. I had DoT on with the two cloudfare servers (1.1.1.1 and 1.0.0.1).. with DNSSEC to yes and "Validate unsigned DNSSEC replies" to yes. This setup worked fine for about 4 hours. Then I tried to get to youtube and found it wouldn't resolve. When I set "Validate unsigned DNSSEC replies" to no it worked again. I can get it to fail again by just setting "Validate unsigned DNSSEC replies" back to yes.

thoughts?

your resolver doesn't validate those signatures via upstream before sending them to dnsmasq to be cached so, so dnsmasq blocks the replies.

 

[RMerlin]

384.11 final is now available.

I will keep this thread open for another day or two as there are currently ongoing discussions within it, however please move to the new thread for any new discussions surrounding 384.11.

 

[Swistheater]

That didn't work either thanks for the try i'll have to wait for merlin's fix.

it is probably going to have to wait for asus to finish their handy work as merlin has no way to really test it if he attempts to fix it. It is better not to muck around to much when asus hasn't fully finished what they are attempting to do.

 

[dvohwinkel]

your resolver doesn't validate those signatures via upstream before sending them to dnsmasq to be cached so, so dnsmasq blocks the replies.

So what do I need to do to prevent it ? turn on "Forward local domain queries to upstream DNS"?

 

[Swistheater]

So what do I need to do to prevent it ? turn on "Forward local domain queries to upstream DNS"?

no - turn off validate unsigned replies.

 

[dvohwinkel]

no - turn off validate unsigned replies.

But that defeats the point of DNSSEC right?

 

[Swistheater]

So what do I need to do to prevent it ? turn on "Forward local domain queries to upstream DNS"?

Alternatively you could turn off dnssec on the router and make two scripts using ssh and putty

cat << EOF > /jffs/configs/dnsmasq.conf.add
#
proxy-dnssec
EOF

and

cat << EOF > /jffs/scripts/stubby.postconf
#
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_insert "  - GETDNS_TRANSPORT_TLS" "dnssec_return_status: GETDNS_EXTENSION_TRUE" $CONFIG
EOF

and type service restart_stubby
into putty terminal
then run your dnssec test - this should provide enough dnssec.
*note it will still show you fail the cloudflare test page because of their lack of dnssec support.

 

[Swistheater]

do you think i mucked up my router then?

no, the options you tried would be erased after you tell it to format jffs on the administration page. and then things would be put back to the way it was after a reboot.

or you could type "rm -rf /jffs/scripts/wan-start" into putty and it will delete the script
and things will be back to normal once you reboot.

 

[Swistheater]

Alternatively you could turn off dnssec on the router and make two scripts using ssh and putty

cat << EOF > /jffs/configs/dnsmasq.conf.add
#
proxy-dnssec
EOF

and

cat << EOF > /jffs/scripts/stubby.postconf
#
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_insert "  - GETDNS_TRANSPORT_TLS" "dnssec_return_status: GETDNS_EXTENSION_TRUE" $CONFIG
EOF

and type service restart_stubby
into putty terminal
then run your dnssec test - this should provide enough dnssec.
*note it will still show you fail the cloudflare test page because of their lack of dnssec support.

this may also require you to do
service restart_dnsmasq
instead of service restart_stubby because you want it to add that dnsmasq addition as well.

 

[dvohwinkel]

Alternatively you could turn off dnssec on the router and make two scripts using ssh and putty

cat << EOF > /jffs/configs/dnsmasq.conf.add
#
proxy-dnssec
EOF

and

cat << EOF > /jffs/scripts/stubby.postconf
#
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_insert "  - GETDNS_TRANSPORT_TLS" "dnssec_return_status: GETDNS_EXTENSION_TRUE" $CONFIG
EOF

and type service restart_stubby
into putty terminal
then run your dnssec test - this should provide enough dnssec.
*note it will still show you fail the cloudflare test page because of their lack of dnssec support.

So this is not a bug? We need to script around this?

 

[Swistheater]

So this is not a bug? We need to script around this?

the built in method tells dnsmasq to do the dnssec validation downstream- the issue is if your server(cloudflare) does not resolve certain signatures- dnsmasq will see it as a no go. where as if you let stubby do dnssec then it happens there at the connection point allowing the page to load- it just does not get flagged as invalid, just because cloudflare doesn't validate that type of signature.

 

[dvohwinkel]

the built in method tells dnsmasq to do the dnssec validation downstream- the issue is if your server(cloudflare) does not resolve certain signatures- dnsmasq will see it as a no go. where as if you let stubby do dnssec then it happens there at the connection point allowing the page to load- it just does not get flagged as invalid, just because cloudflare doesn't validate that type of signature.

So I need to install stubby? I thought stubby was going away now that it's functionality is built into 384.11