What's new

Beta Asuswrt-Merlin 386.1 Beta (stage 2) 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!

Status
Not open for further replies.
When I attempted to upgrade RT-AC68U from Beta 3 to Beta 4, I encountered the following warning after uploading firmware to router:
Code:
To comply with regulatory amendments, we have modified
our certification rule to ensure better firmware quality.
This version is not compatible with all previously released
ASUS firmware and uncertified third party firmware. Please
check our official websites for the certified firmware.
The router remained at Beta 3 after reboot.
 
Last edited:
When I attempted to upgrade RT-AC68U from Beta 3 to Beta 4, I encountered the following warning after uploading firmware to router:
Code:
To comply with regulatory amendments, we have modified our certification rule to ensure better firmware
quality. This version is not compatible with all previously released ASUS firmware and uncertified third party
firmware. Please check our official websites for the certified firmware.
The router remained at Beta 3 after reboot.
I got the same message on the AC68U at our holiday house in the post before yours
 
Hi @RMerlin

-Finally, QoS seem working fine again.
-SpeedTest work without any issue in my side (AX58U), it seems that GUI SpeedTest "skip" QoS doing the test, but work fine.
-My FW with IPSET scripts work fine too, the same for my OpenVPN settings
-Maybe some issues with IPv6, but I haven't had time to look at it, the problem could be on my side
 
I got the same message on the AC68U at our holiday house in the post before yours

Double check that you are trying to flash the correct model. I had no issue upgrading my own RT-AC66U_B1 here.
 
RT-AX86U flashed b4 over Asus stock Version 3.0.0.4.386.41535 [same as GPL used in your commits].
I am puzzled though? - stock allows me to set cpuwait on or off - also cpuspeed ... and status is shown in response to "pwr show" - BUT in your b4 both these settings are "N/A" and no amount of pwr config commands will change them ??

Also note from your post #2 above ...
RT-AX86U and RT-AX88U syslog spam when using Guest Network 1 (issue that will have to be resolved by Asus, only workaround is to switch to Guest Network 2)
In Asus release stock 386.41535 for the RT-AX86U this issue has been fixed - and the fix seems to have carried through to your b4 :).

Edit: forgot to mention I did indeed factory reset after flashing 386.1_b4 from stock [essential if you want all the add-ons per my signature to work properly if coming from stock]
 
Last edited:
I still see my log flooded with this "debug-info" several times per second. I posted the same question in the Alpha-thread, but now Asus have released 386 to public so shouldn't it be turned off?!
PS. I'm only using Guest 2 so should't be the Guest 1 bug spamming the logs. ;)

Code:
Jan  9 06:43:04 kernel: CONSOLE: 098224.813 wl1: wlc_ampdu_recv_addba_resp: xx:xx:xx:xx:xx:xx: Failed. status 37 wsize 64 policy 1
Jan  9 06:43:04 kernel: CONSOLE: 098224.814 wl1: wlc_ampdu_recv_addba_resp: xx:xx:xx:xx:xx:xx: Failed. status 37 wsize 64 policy 1
Jan  9 06:43:04 kernel: CONSOLE: 098224.814 wl1: wlc_ampdu_recv_addba_resp: xx:xx:xx:xx:xx:xx: Failed. status 37 wsize 64 policy 1
Jan  9 06:43:04 kernel: CONSOLE: 098224.814 wl1: wlc_ampdu_recv_addba_resp: xx:xx:xx:xx:xx:xx: Failed. status 37 wsize 64 policy 1
Jan  9 06:43:04 kernel: CONSOLE: 098224.814 wl1: wlc_ampdu_recv_addba_resp: xx:xx:xx:xx:xx:xx: Failed. status 37 wsize 64 policy 1
Jan  9 06:43:04 kernel: CONSOLE: 098224.976 wl1: wlc_ampdu_recv_addba_resp: xx:xx:xx:xx:xx:xx: Failed. status 37 wsize 64 policy 1
Jan  9 06:43:04 kernel: CONSOLE: 098225.014 wl1: wlc_ampdu_recv_addba_resp: xx:xx:xx:xx:xx:xx: Failed. status 37 wsize 64 policy 1
Jan  9 06:43:05 kernel: CONSOLE: 098225.824 wl1: wlc_ampdu_recv_addba_resp: xx:xx:xx:xx:xx:xx: Failed. status 37 wsize 64 policy 1
Jan  9 06:43:05 kernel: CONSOLE: 098225.934 wl1: wlc_ampdu_recv_addba_resp: xx:xx:xx:xx:xx:xx: Failed. status 37 wsize 64 policy 1
Jan  9 06:43:06 kernel: CONSOLE: 098226.805 wl1: wlc_ampdu_recv_addba_resp: xx:xx:xx:xx:xx:xx: Failed. status 37 wsize 64 policy 1
Jan  9 06:43:06 kernel: CONSOLE: 098226.805 wl1: wlc_ampdu_recv_addba_resp: xx:xx:xx:xx:xx:xx: Failed. status 37 wsize 64 policy 1
Jan  9 06:43:06 kernel: CONSOLE: 098226.805 wl1: wlc_ampdu_recv_addba_resp: xx:xx:xx:xx:xx:xx: Failed. status 37 wsize 64 policy 1
 
Last edited:
Double check that you are trying to flash the correct model. I had no issue upgrading my own RT-AC66U_B1 here.
Correction to my previous post - it's an RT-AC67U at the holiday house, but an AC68U - but the AC68U firmware has always worked (I believe the routers are near identical other than the non-removal antenna on the AC67U). I just re-downloaded RT-AC68U_386.1_beta4.zip - I still get the "To comply with regulatory amendments, we have modified our certification rule to ensure better firmware quality. This version is not compatible with all previously released ASUS firmware and uncertified third party firmware. Please check our official websites for the certified firmware." After a reboot, I'm still on beta3.
 
I can confirm that with 41535 on my AX88u and two ac68u aimesh nodes if I enable a guest network which has no intranet access and sync to all nodes then devices on those nodes will drop many packets. Changing to not sync to aimesh nodes fixed it. (Reboot of nodes needed this time).

Believe from chatting with others that this is only happening with ac68u nodes.

AX88u as indicated still spams log with buggy protocol error and Speedtest on device is slow.
 
Anyone with the AX86U has scribe installed? Mine still has the rolling kernel alarm whenever scribe is installed. I also have diversion, skynet, connmon, ntpmerlin and scmerlin installled.

kernel: _blog_emit, blogp = 0x6
kernel: _blog_emit, blogp = 0x4
kernel: _blog_emit, blogp = 0x2240
kernel: _blog_emit, blogp = 0x1a68
kernel: _blog_emit, blogp = 0x2

Other than that - LE fix is in. I have the LE cert installed and working normally.
 
Hi @RMerlin

-Finally, QoS seem working fine again.
-SpeedTest work without any issue in my side (AX58U), it seems that GUI SpeedTest "skip" QoS doing the test, but work fine.

It became apparent to me after this update, the built in speedtest is supposed to bypass QOS and bandwidth limits so you can get your baseline speeds anytime you want without having to disable anything first. Pretty useful tool actually. If true, Asus should state that in the description to avoid confusion.
 
Thanks for your hard work @RMerlin

Can you confirm your latest advice regarding firmware for AiMesh nodes. Are they better also running your releases, or stock firmware (in this case also based on the same GPL version)?
 
Big Thanks to RMerlin :) I would like to report:

I have been running smoothly with Merlin 386.1_beta4 for over an 1.5 hour, my configuration includes using AiMesh 2.0 with DEFAULT settings:
  • Solid Ethernet Backhaul
  • Excellent Wifi (AiMesh Roaming/Steering)
  • Good Performance (Upload/Download: Wifi (ac) about 400mbps, Wired about 930mbps)
Hoping that it can be a useful comparison for others with similar configuration.

My Configuration:
  • AiMesh Router: AX88U 386.1_beta4 + 2 x AiMesh Nodes: AC86U 386.1_beta4
  • Backhaul (Priority:"Auto", Type:"Wired"), Asus GX-U1051 5-Port Gigabit Switch from Router to Nodes, ISP: 1 Gbps Fibre
My steps to Upgrade from Merlin 386.1_beta3 -> 386.1_beta4 (dirty flashed):

(1) Upgrade AiMesh Nodes:
  • Administration -> Upgrade Firmware ->
    • Select and Upgrade AiMesh Node (One Node at a time)
(2) Upgrade AiMesh Router:
  • Administration -> Upgrade Firmware -> Select and Upgrade
(3) I tried to leave NVRAM using Merlin FW default values, except with the following changes:
  • Enabled AiProtection: OFF ON (after moving to 386.1_beta4b-gb9175c6a96)
    • Turning ON significantly impact Speedtest from my MacBookPro from 930mbps to 30mbps
  • USB Application
    • UPnP Media Server: OFF
    • Samba Share: OFF
  • Wireless:
    • 2.4 GHz: Fixed Channel Bandwidth 20MHz, Control Channel: Auto, Explicit & Universal Beamforming: Disable
    • 5.0 GHz: Fixed Channel Bandwidth 80MHz, Control Channel: Auto
  • WAN DDNS:
    • Using Asus DDNS Service with Let’s Encrypt (Let’s Encrypt working now)
  • IPv6: Enable
    • Native
  • VPN Servers (Connecting one at a time from the following clients):
    • OpenVPN works with MacBookPro 3.8.5beta02 (build 5620), iPhoneXsMax iOS OpenVPN Connect 3.2.2
    • IPSec works with MacBookPro & iPhoneXsMax Native Configurations
    • Instant Guard works with iPhoneXsMax iOS Instant Guard
(6) Reboot AiMesh Network
  • AiMesh -> System Settings -> Reboot (AiMesh Router & Nodes)
 
Last edited:
Hi @RMerlin

WAN Aggregation seem working again. AX86U beta4

speed.PNG


Thank you! ;)
 
Last edited:
Checked mine too... also disabled.

ASUSWRT-Merlin RT-AC86U 386.1_beta4 Fri Jan 8 22:42:18 UTC 2021
admin@RT-AC86U-XXXXXXXXXX:/tmp/home/root# pwr show

Power Management Configuration
Functional Block Status
CPU Wait DISABLED
Ethernet Auto Power Down ENABLED
Energy Efficient Ethernet DISABLED
Switch Deep Green Mode ENABLED (status:Deactivated)
admin@RT-AC86U-XXXXXXXXX:/tmp/home/root#

Same issue here too
As workaround I'm using a super simple startup script in order to enable it:

file /jffs/scripts/cpuwait, called by services-start
Code:
#!/bin/sh
pwr config --wait on
 
I've tested the new Beta 4 version. Aiprotection time scheduling works only restricting access to web pages, but it doesn't restrict other services (spotify, for example).
 
  • Like
Reactions: Civ
Checked mine too... also disabled.

ASUSWRT-Merlin RT-AC86U 386.1_beta4 Fri Jan 8 22:42:18 UTC 2021
admin@RT-AC86U-XXXXXXXXXX:/tmp/home/root# pwr show

Power Management Configuration
Functional Block Status
CPU Wait DISABLED
Ethernet Auto Power Down ENABLED
Energy Efficient Ethernet DISABLED
Switch Deep Green Mode ENABLED (status:Deactivated)
admin@RT-AC86U-XXXXXXXXX:/tmp/home/root#
The same here - cpu wait remains disabled
 
Hi Merlin,
just flashed Beta4 over Beta3 on a AC86U as an Access-Point. All went fine, but if i tried to make a backup with latest nsru it stopped at Line "VPN Admin". Several reboots not helped. On my main router (AX88U) all went fine, backup with nsru worked fine.
Greetings
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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