What's new

[Beta] Asuswrt-Merlin 384.11 Beta is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

RT- AC87U.
Dirty flash over 384.10_2. last factory reset is maybe 2-3 releases away.
SNMP not responding and getting this error when disable/enable SNMP.

Maybe time for a factory reset but I will save that for the FW release. So just reporting in case someone see the same behaviour.

Code:
Apr 27 09:05:28 rc_service: httpds 243:notify_rc restart_snmpd
Apr 27 09:05:29 kernel: SQUASHFS error: xz_dec_run error, data probably corrupt
Apr 27 09:05:29 kernel: SQUASHFS error: squashfs_read_data failed to read block 0xf00a83
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read data cache entry [f00a83]
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read page, block f00a83, size 719c
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read data cache entry [f00a83]
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read page, block f00a83, size 719c
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read data cache entry [f00a83]
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read page, block f00a83, size 719c
....
....
....
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read page, block f00a83, size 719c
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read data cache entry [f00a83]
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read page, block f00a83, size 719c
Apr 27 09:05:30 nat: apply nat rules (/tmp/nat_rules_vlan2_vlan2)

guess, now it's fixed in git.
 
Which one did you have? Did the 5300 have the same problem of no GUI access after flash? Thought it was only 3100+87U.
No it was not mentioned to have issues but i saw a new commit had been released by merlin today- I am guessing he did uniform adjustments to all the firmware.
 
RT-AC66U_B1. Dirty flashed 384.11_beta1b over 384.10_2 with one small incident. OpenVPN Server started fine but the certificates had been replaced. Had to copy and paste and then client would connect.

WAN-->Internet Connection
Connect to DNS Server Automatically-->Yes
Forward Local Domain Queries to Upstream DNS-->No
Enable DNS Rebind Protection-->Yes
Enable DNSSEC support-->Yes
DNS Privacy Protocol-->DNS over TLS
DNS-Over-TLS Profile-->Strict
Cloudflare DNS Servers set

LAN-->DNS Filter
Enable DNS-based filtering-->OFF

Thank you to RMerlin and all the great posts.
 
Last edited:
guess, now it's fixed in git.

Confirmed, that kernel fix fixed it with one of the corrupted test image I kept at hand. I'll be able to keep thumb compression enabled for beta 2.
 
Confirmed, that kernel fix fixed it with one of the corrupted test image I kept at hand. I'll be able to keep thumb compression enabled for beta 2.
*1 million likes*
 
Yes
Code:
# cat /jffs/scripts/wan-start
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.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
#

Can you retest without that script? GPL 45713 should have resolved this issue. Also check the state of "Accept Default Route" on the IPv6 webui page.
 
I have regenerated all the SDK6/SDK7 firmware images with the new compression option disabled. They should appear on Onedrive/Sourceforce in a little while. The ZIP filename will have beta1b . The firmware version will still show as beta1 - I haven't recompiled the code, simply rebuilt the .trx files with the mksquashfs change.

I recommend everyone to upgrade, just in case there might also be filesystem corruption issues with other models.

I haven't rebuilt the HND models (AC86U and AX88U) because they use ubifs, as well as a newer kernel, so in theory these should be fine.

Interesting thing is the corrupted images will read just fine on my Linux VM, but mounting them on a loopback on the routers themselves will generate read errors while accessing certain files. I suspect it could be a bug in the older kernel, or an incompatibility between mksquashfs and these kernel releases.

I'm not 100% sure this was the cause, but it's what made the most sense (unfortunately, I cannot reproduce the problem every time I build an image). Only testing in the long run will confirm this was the issue.

I loaded the firmware onto a usb key
Then SSH'ed into the router
Then ran mtd-write2 /mnt/sda1/file.trx linux && reboot where file.trx was the new beta1b for the AC3100

Back in business (on both AC3100 routers)

Thanks!
 
"View List" for clients on the Network Map page always displays zero now for me. I understand this is an ASUS issue, but it at least used to be inconsistent. Now it's consistently zero. FYI. (Beta1b)
 
Last edited:
So there is any agreement as to what setup works better or which would be the best setup when using a VPN client with DOT?

Accept Configuration: Disabled
Policy Rules: Strict
Connect to DNS servers automatically = Yes
DOT - enabled


or

Accept Configuration: Disabled
Policy Rules: Strict
Connect to DNS servers automatically = No
WAN DNS 1 & 2 = Cloudflare's/VPN/Other servers
DOT - enabled


or

Accept Configuration: Strict
Policy Rules: Strict
Connect to DNS servers automatically = Yes
DOT - enabled

or

Accept Configuration: Strict
Policy Rules: Strict
Connect to DNS servers automatically = No
WAN DNS 1 & 2 = Cloudflare's/VPN/Other servers
DOT - enabled

or

Accept Configuration: Exclusive
Policy Rules: Strict
Connect to DNS servers automatically = Yes
DOT - enabled

or

Accept Configuration: Exclusive
Policy Rules: Strict
Connect to DNS servers automatically = No
WAN DNS 1 & 2 = Cloudflare's/VPN/Other servers
DOT - enabled

What ensures that your setup is working better? Better speed? No DNS leaks? Anything else? I appreciate your input. If there are any additional tweaks for your setup, feel free to include it.
 
Can you retest without that script? GPL 45713 should have resolved this issue. Also check the state of "Accept Default Route" on the IPv6 webui page.
Without the script, a reboot resulted in no IPv6 gateway like before.
  • /proc/sys/net/ipv6/conf/eth0/accept_ra is 0
  • WAN IPv6 Gateway is blank but all else is OK
  • Solved by setting /proc/sys/net/ipv6/conf/eth0/accept_ra to 1
IPv6_settings.png
 
Without the script, a reboot resulted in no IPv6 gateway like before.
  • /proc/sys/net/ipv6/conf/eth0/accept_ra is 0
  • WAN IPv6 Gateway is blank but all else is OK
  • Solved by setting /proc/sys/net/ipv6/conf/eth0/accept_ra to 1
View attachment 17253
yea they broke it in GPL of ASUS RT-AX88U for firmware 3.0.0.4.384.5951

they know about it though so hopefully they fix it in their next gpl release.
 
I thought I had a handle on understanding the "why" behind the Clouldflare test site (1.1.1.1/help) not working/verifying DOT the way it used to under the old Stubby installer:
as mentioned by Rmerlin in the first post, BUT, why then do I keep seeing some users posting screenshots in this thread of it working again? What tricks are they employing to get DOT/ TLS1.3 showing as "green", as they don't anymore for me presently, but did under Stubby.
 
they are testing it while using browsers that support tls 1.3 as main connection
 
this is an example from google chrome.
upload_2019-4-27_22-56-44.png
 
they may also might not be using strict dnssec validation- if that is turned on the secure dns option appears orange instead of green.
 
This is my result of Chrome browser on Linux, using RMerlin defaults, DNSSEC validation off.

screenshot-www-cloudflare-com-2019-04-27-20-32-10.png
 
Without the script, a reboot resulted in no IPv6 gateway like before.
  • /proc/sys/net/ipv6/conf/eth0/accept_ra is 0
  • WAN IPv6 Gateway is blank but all else is OK
  • Solved by setting /proc/sys/net/ipv6/conf/eth0/accept_ra to 1
View attachment 17253

Oh, you have an RT-AX88U. The fix is in the mainline GPL, not the RT-AX88U GPL.

That page got a new setting to accept/reject routes.

What ensures that your setup is working better? Better speed? No DNS leaks?

What do you call a "DNS leak"? because technically, it means "any DNS queries sent to a DNS server that is NOT the one from the VPN"...

The DNS will have no impact on speed.

why then do I keep seeing some users posting screenshots in this thread of it working again?

Because they most likely disabled strict DNSSEC mode, which basically tells dnsmasq to accept unsigned requests, even if it means these could be forged. So, basically removing the layer of security provided by DNSSEC.

TLS1.3 showing as "green",

This is related to the browser, NOT to the router.
 
I have kept DNSSEC on. Since there are also other non browser devices that are not capable to run with DOT.
DNSfilter is set to Router.

This is my result with version1b:
  1. Router: DNSSEC validation on, DOT enabled, Cloudflare browser security check result: Secure DNS=Fail, DNSSEC=Pass, tcpdump on port 854 shows encrypted messages.
  2. Router: DNSSEC validation off, DOT enabled, Cloudflare browser security check result: Secure DNS=Pass, DNSSEC=Pass, tcpdump on port 854 shows encrypted messages.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top