[Beta] Asuswrt-Merlin 384.12 Beta is now available

Swistheater · Jun 13, 2019

Delusion said:
Just compiled Beta 2 . Works great. However , after the the update I had to remove my DNS settings ( I use 'secure dns' with dot and DNSSEC , much faster resolving than cloudflare ,at least for me) because WAN didn't connect, usb showed unmounted and the clock was not set . I re-applied DNS settings after the connection was established. I guess this happened because DNS cache was set to YES on tools page?

i always unmount my hard drive and disable jffs before flashing for these specific reasons.

Swistheater · Jun 13, 2019

is this okay to see when updating the firmware

Code:

May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 527c12, size b79c
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [527c12]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 527c12, size b79c
May  5 01:05:04 kernel: <3>SQUASHFS error: xz_dec_run error, data probably corrupt
May  5 01:05:04 kernel: <3>SQUASHFS error: squashfs_read_data failed to read block 0x687047
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: xz_dec_run error, data probably corrupt
May  5 01:05:04 kernel: <3>SQUASHFS error: squashfs_read_data failed to read block 0x691ecb
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <4>dhd_detach(): thread:dhd_watchdog_thread:84 terminated OK
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unabl ^C read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <3>SQUASHFS error: xz_dec_run error, data probably corrupt
May  5 01:05:04 kernel: <3>SQUASHFS error: squashfs_read_data failed to read block 0x687047
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <4>dhthread:80 terminated OK

dave14305 · Jun 13, 2019

Swistheater said:

is this okay to see when updating the firmware

Code:

May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 527c12, size b79c
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [527c12]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 527c12, size b79c
May  5 01:05:04 kernel: <3>SQUASHFS error: xz_dec_run error, data probably corrupt
May  5 01:05:04 kernel: <3>SQUASHFS error: squashfs_read_data failed to read block 0x687047
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <3>SQUASHFS error: xz_dec_run error, data probably corrupt
May  5 01:05:04 kernel: <3>SQUASHFS error: squashfs_read_data failed to read block 0x691ecb
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <4>dhd_detach(): thread:dhd_watchdog_thread:84 terminated OK
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unabl ^C read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [691ecb]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 691ecb, size acb4
May  5 01:05:04 kernel: <3>SQUASHFS error: xz_dec_run error, data probably corrupt
May  5 01:05:04 kernel: <3>SQUASHFS error: squashfs_read_data failed to read block 0x687047
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read data cache entry [687047]
May  5 01:05:04 kernel: <3>SQUASHFS error: Unable to read page, block 687047, size ae84
May  5 01:05:04 kernel: <4>dhthread:80 terminated OK

See Merlin’s answer here: [Release] Asuswrt-Merlin 384.11 is available

Swistheater · Jun 13, 2019

dave14305 said:
See Merlin’s answer here: [Release] Asuswrt-Merlin 384.11 is available

thanks for the quick response it had me coooonncerrrneed lol

the main concerning part was the update meter went from 70percent to
login screen, like it was instantly finished at 70 percent.

Swistheater · Jun 13, 2019

okay so initial thoughts on some of the new recent changes,,, Merlin good job on fixing the wait times. It improves the overall boot performance and fixes a lot of waiting for wan up issues, also the boot up logs are no longer half of the syslog.

Vexira · Jun 13, 2019

RMerlin said:
The issue seems to mostly happen on firmware upgrades, tho it can also be triggered by a reboot.

Strange I'll have to check my router again I know triggered a reset on QoS bandwidth and packet overhead settings by configuring the priorities via the app it set it to automatic bandwidth it was odd.

Though it seems to be behaving it self so far since the last time I checked so I'm quite curious if it's a revision based issue and I'm just lucky or its because my unit hasn't been flashed as many times as other people's because it's new.

Though I'm hoping the fix will come soon, just incase the issue manifests it's self on my unit

so far I'm enjoying the full cone nat and gta v has open Nat on PC now.

enanolex · Jun 13, 2019

Im on RT-AC68U_384.12_alpha2-g6a46c21cce and it works solid on voipo. This new beta is causing voipo to not receive calls intermittently so I switched back to alpha.

Vexira · Jun 14, 2019

enanolex said:
Im on RT-AC68U_384.12_alpha2-g6a46c21cce and it works solid on voipo. This new beta is causing voipo to not receive calls intermittently so I switched back to alpha.

Are you using upnp or keep alive for Nat traversal and more importantly is it. An IP phone or a VoIP ATA?

enanolex · Jun 14, 2019

Vexira said:
Are you using upnp or keep alive for Nat traversal and more importantly is it. An IP phone or a VoIP ATA?

I have upnp enabled and using VOIP ATA (obihai202)
I even tried enabled and disabled SPI Passthrough thinking it was that, it wasn't, currently set to disabled. Alpha works good.

Vexira · Jun 14, 2019

enanolex said:
I have upnp enabled and using VOIP ATA (obihai202)
I even tried enabled and disabled SPI Passthrough thinking it was that, it wasn't, currently set to disabled. Alpha works good.

Which router and ata if you don't mind me asking.?

I have mine reboot after the router does at night

But I have my Nat set to full cone because I'm using an rt ax88u if it's below the 86u it's symetric.

enanolex · Jun 14, 2019

I am not sure, but I always suspected the NAT Acceleration was causing problems with voipo. So Ive always had it disabled, if anyone is having problems with voip.

Vexira · Jun 14, 2019

enanolex said:
I am not sure, but I always suspected the NAT Acceleration was causing problems with voipo. So Ive always had it disabled, if anyone is having problems with voip.

Mine works with acceleration enabled, but then again it depends on the type of Nat if you have symetric Nat you are best off running keep alive as Nat traversal.

unclebuk · Jun 14, 2019

Can someone explain the implication of this firmware change, and does it require intervention and/or setting changes to avoid using ISP DNS?

384.12 (xx-xxx-2019)
- CHANGED: The router will now use ISP-provided resolvers
instead of local dnsmasq when attempting to
resolve addresses, for improved reliability.
This reproduces how stock firmware behaves.
This only affects name resolution done
by the router itself, not by the LAN clients.

Thanks in advance, much obliged.
bUk

dave14305 · Jun 14, 2019

unclebuk said:
Can someone explain the implication of this firmware change, and does it require intervention and/or setting changes to avoid using ISP DNS?

384.12 (xx-xxx-2019)
- CHANGED: The router will now use ISP-provided resolvers
instead of local dnsmasq when attempting to
resolve addresses, for improved reliability.
This reproduces how stock firmware behaves.
This only affects name resolution done
by the router itself, not by the LAN clients.

Thanks in advance, much obliged.
bUk

“ISP-provided” really means whatever your WAN DNS servers are set to. If it’s set to a Connect to DNS Server Automatically, it will use whatever your ISP provides through DHCP. Otherwise it uses whatever you’ve entered in DNS 1 and 2 fields. DNS Privacy (DoT) servers are not considered even if you’ve turned that on.

Swistheater · Jun 14, 2019

dave14305 said:
“ISP-provided” really means whatever your WAN DNS servers are set to. If it’s set to a Connect to DNS Server Automatically, it will use whatever your ISP provides through DHCP. Otherwise it uses whatever you’ve entered in DNS 1 and 2 fields. DNS Privacy (DoT) servers are not considered even if you’ve turned that on.

As we so elegantly pointed out before, the only real difference in having ISP being used vs Defining DNS1 and DNS2, is that with ISP DNS, the router will define
server=/some isp domain/ispDNS1
server=/some isp domain/ispDNS2
server=127.0.1.1
inside /tmp/resolv.dnsmasq, /etc/resolv.conf will just be 127.0.0.1, and /tmp/resolv.conf will be ISP DNS.
where as if you define a DNS1 and DNS2
you will see
server=127.0.1.1
inside /tmp/resolv.dnsmasq, /etc/resolv.conf will be 127.0.0.1, and /tmp/resolv.conf will be defined DNS1 and DNS2.
I have not noticed any real benefit of using ISP DNS with the ISP domains defined inside resolv.dnsmasq pointed at ISP's DNS, but for some people, I assume, this may effect certain aspects of features provided by the ISP.
All my test have concluded I can define a wan dns1 and wan dns2 and my services were not impacted with certain ISP features.
I have to say though, the way merlin and themiron have came up with this design was very well thought out and is actually working very well aside from the hiccups other people may have experienced causing merlin to place default behavior back on "No" to allow the use of local caching to not be the default.

BLuFeNiX · Jun 14, 2019

Just flashed my RT-AC3200 with this build (RT-AC3200_384.12_beta1-g69e0eaefe1) yesterday, and it's making my router stop working. Here are some details:

1. All my clients lose wifi, and cannot re-authenticate (2 of my 3 SSIDs were still broadcasting -- the missing one is the one I was previosuly connected to)
2. Wired connections fail as well (I have a secondary router behind my 3200, connected via ethernet, and it lost connection to the internet)
3. rebooting the router manually (on/off switch) will bring it back up for a bit, but it will drop all clients again in a mater of time (a couple of hours, I think, but I have not measured). Did this twice.
4. I turned on a lot of options (after flashing) that I have not used before (firewall stuff, changed DNS, QoS, etc.). I can attempt to enumerate them if this is valuable information.
5. I was on a slightly older firmware version when I first flashed 384.12_beta1, though I don't know which one. I have now flashed RT-AC3200_384.11_2, but will not be able to confirm the problem is gone for a few hours at least.

Let me know if you need any other information. I can attempt to reproduce this problem if need be, but this is my primary router so I will need to do it when no one is online.

Swistheater · Jun 14, 2019

Nicholas C Montgomery said:
Just flashed my RT-AC3200 with this build (RT-AC3200_384.12_beta1-g69e0eaefe1) yesterday, and it's making my router stop working. Here are some details:

1. All my clients lose wifi, and cannot re-authenticate (2 of my 3 SSIDs were still broadcasting -- the missing one is the one I was previosuly connected to)
2. Wired connections fail as well (I have a secondary router behind my 3200, connected via ethernet, and it lost connection to the internet)
3. rebooting the router manually (on/off switch) will bring it back up for a bit, but it will drop all clients again in a mater of time (a couple of hours, I think, but I have not measured). Did this twice.
4. I turned on a lot of options (after flashing) that I have not used before (firewall stuff, changed DNS, QoS, etc.). I can attempt to enumerate them if this is valuable information.
5. I was on a slightly older firmware version when I first flashed 384.12_beta1, though I don't know which one. I have now flashed RT-AC3200_384.11_2, but will not be able to confirm the problem is gone for a few hours at least.

Let me know if you need any other information. I can attempt to reproduce this problem if need be, but this is my primary router so I will need to do it when no one is online.

screen shots of your
Lan >DHCP page
WAN > internet connection page
and
tools >others page

should be a good place to start.
The only notable change is the switch from using local cache resolver to using upstream.( router behavior)

MDM · Jun 14, 2019

Nicholas C Montgomery said:
5. I was on a slightly older firmware version when I first flashed 384.12_beta1, though I don't know which one. I have now flashed RT-AC3200_384.11_2, but will not be able to confirm the problem is gone for a few hours at least.

This! You jumped too far in versions, and obviously need to reset to factory defaults, and reconfigure by hand.
Sorry, but this is probably the only way...

BLuFeNiX · Jun 14, 2019

MDM said:
This! You jumped too far in versions, and obviously need to reset to factory defaults, and reconfigure by hand.
Sorry, but this is probably the only way...

I would be surprised if I needed to iterate through each version in order to prevent bugs like this from occurring. Is there any documentation that mentions this? I think I was only a couple of releases behind. Also, everything seems fine after flashing the latest stable with no factory reset.

Swistheater said:
screen shots of your
Lan >DHCP page
WAN > internet connection page
and
tools >others page

should be a good place to start.
The only notable change is the switch from using local cache resolver to using upstream.( router behavior)

I will reflash and collect this information when I find time. Thanks.

Vexira · Jun 14, 2019

Nicholas C Montgomery said:
Just flashed my RT-AC3200 with this build (RT-AC3200_384.12_beta1-g69e0eaefe1) yesterday, and it's making my router stop working. Here are some details:

1. All my clients lose wifi, and cannot re-authenticate (2 of my 3 SSIDs were still broadcasting -- the missing one is the one I was previosuly connected to)
2. Wired connections fail as well (I have a secondary router behind my 3200, connected via ethernet, and it lost connection to the internet)
3. rebooting the router manually (on/off switch) will bring it back up for a bit, but it will drop all clients again in a mater of time (a couple of hours, I think, but I have not measured). Did this twice.
4. I turned on a lot of options (after flashing) that I have not used before (firewall stuff, changed DNS, QoS, etc.). I can attempt to enumerate them if this is valuable information.
5. I was on a slightly older firmware version when I first flashed 384.12_beta1, though I don't know which one. I have now flashed RT-AC3200_384.11_2, but will not be able to confirm the problem is gone for a few hours at least.

Let me know if you need any other information. I can attempt to reproduce this problem if need be, but this is my primary router so I will need to do it when no one is online.

Factory reset if you flashed form atlest 3 versions back you have to because the settings are extremely different.

Thread starter	Title	Forum	Replies	Date
	Beta Asuswrt-Merlin 3006.102.2 Beta is now available for Wifi 7 devices	Asuswrt-Merlin	69	Oct 12, 2024
	Beta Asuswrt-Merlin 386.14 beta is now available	Asuswrt-Merlin	35	Jul 1, 2024
	Beta Asuswrt-Merlin 3004.388.8 beta is now available	Asuswrt-Merlin	155	Jun 23, 2024
	Beta Asuswrt-Merlin 3006.102.1 Beta is now available for WIfi 7 devices	Asuswrt-Merlin	97	Jun 8, 2024
	Beta Asuswrt-Merlin 3004.388.7 beta is now available	Asuswrt-Merlin	123	Apr 20, 2024
	Beta Asuswrt-Merlin 386.13 beta is now available for AC models	Asuswrt-Merlin	32	Mar 28, 2024
	Beta Asuswrt-Merlin 3004.388.6 Beta is now available	Asuswrt-Merlin	279	Jan 5, 2024
	Beta Asuswrt-Merlin 3004.388.5-beta is now available	Asuswrt-Merlin	58	Nov 26, 2023
S	Anyone else having issues trying to flash the newest merlin (stable or beta) to the GT-0AXE11000?	Asuswrt-Merlin	4	Dec 1, 2023
B	Unable to establish VPN connection to my PiVPN (ovpn) from my Asus RT-AC86U running Asuswrt-Merlin 386.14	Asuswrt-Merlin	1	Sunday at 3:25 PM

[Beta] Asuswrt-Merlin 384.12 Beta is now available

Very Senior Member

Very Senior Member

Part of the Furniture

Very Senior Member

Very Senior Member

Part of the Furniture

New Around Here

Part of the Furniture

New Around Here

Part of the Furniture

New Around Here

Part of the Furniture

Senior Member

Part of the Furniture

Very Senior Member

New Around Here

Very Senior Member

Senior Member

New Around Here

Part of the Furniture

Similar threads

Similar threads

Support SNBForums w/ Amazon

Sign Up For SNBForums Daily Digest