[Beta] Asuswrt-Merlin 384.12 Beta is now available

[Swistheater]

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]

is this okay to see when updating the firmware

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]

is this okay to see when updating the firmware

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

“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]

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]

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]

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]

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.

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]

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.