What's new

Release ASUS RT-AX56U - Firmware version 3.0.0.4.386.44266

  • 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!

Volt

Regular Contributor
2021/07/14 - 71.6 MBytes

Release notes:
1. Improved system stability.
2. Added IPv6+ in WAN-> Internet Connection.
3. Added Auto firmware upgrade in Administration-->Firwmare Upgrade
4. Fixed envrams exposed issue. Thanks for Quentin Kaiser from IoT Inspector Research Lab contribution.

Please unzip the firmware file first then check the MD5 code.
MD5: a86e0a2edf16fd0b43de8061a88e5838

 
Looks like this firmware has issues with automatic channel selection and, as a result, with 5GHz band in general. On all previous firmware versions, when I select the automatic channel selection for 5GHZ, the router always chooses the channel 100 and stays on this channel forever (I have no radar in vicinity and a couple of other 5GHz networks, all on channel 36).

However, on 3.0.0.4.386.44266, usually after the restart, the 5GHz network appears, but no devices can connect to it. After logging in to the router I see that the router selected channel 36 for some reason. In the log, I see the following messages that I think are related to the problem (never seen them on other firmware versions):

Code:
Jul 15 09:58:26 acsd: acs_candidate_score_intf(1080): eth6: intf check failed for chanspec: 0xe06a
Jul 15 09:58:26 acsd: acs_candidate_score_bgnoise(1500): eth6: bgnoise check failed for chanspec: 0xe06a
Jul 15 09:58:26 acsd: acs_candidate_score_txop(1758): eth6: txop check failed for chanspec: 0xe06a
Jul 15 09:58:26 acsd: acs_candidate_score_intf(1080): eth6: intf check failed for chanspec: 0xe16a
Jul 15 09:58:26 acsd: acs_candidate_score_bgnoise(1500): eth6: bgnoise check failed for chanspec: 0xe16a
Jul 15 09:58:26 acsd: acs_candidate_score_txop(1758): eth6: txop check failed for chanspec: 0xe16a
Jul 15 09:58:26 acsd: acs_candidate_score_intf(1080): eth6: intf check failed for chanspec: 0xe26a
Jul 15 09:58:26 acsd: acs_candidate_score_bgnoise(1500): eth6: bgnoise check failed for chanspec: 0xe26a
Jul 15 09:58:26 acsd: acs_candidate_score_txop(1758): eth6: txop check failed for chanspec: 0xe26a
Jul 15 09:58:26 acsd: acs_candidate_score_intf(1080): eth6: intf check failed for chanspec: 0xe36a
Jul 15 09:58:26 acsd: acs_candidate_score_bgnoise(1500): eth6: bgnoise check failed for chanspec: 0xe36a
Jul 15 09:58:26 acsd: acs_candidate_score_txop(1758): eth6: txop check failed for chanspec: 0xe36a
Jul 15 09:58:26 acsd: eth6: selected channel spec: 0xe06a (100/80)
Jul 15 09:58:26 acsd: eth6: Adjusted channel spec: 0xe06a (100/80)
Jul 15 09:58:26 acsd: eth6: selected channel spec: 0xe06a (100/80)
Jul 15 09:58:26 acsd: acs_set_chspec: 0xe06a (100/80) for reason APCS_INIT
Jul 15 09:58:26 acsd: acs_update_driver(441): acs update failed ret code: -16
Jul 15 09:58:26 acsd: acs_init_run(1065): eth6: update driver failed

Looks like the logic behind the automatic channel selection fails and causes the driver to fail. If I specify the channel 100 manually, everything works fine even after the restart, and there are no errors in the log. I've performed the hard reset twice on this firmware, but it does not help; rolling back to any previous version solves the problem. Interestingly, I found that similar messages were reported for GT-AX11000 and GT-AXE11000.

Has anyone run into the same problem with this firmware?
 
Something may have changed in your Wi-Fi environment then.
 
Looks like this firmware has issues with automatic channel selection and, as a result, with 5GHz band in general. On all previous firmware versions, when I select the automatic channel selection for 5GHZ, the router always chooses the channel 100 and stays on this channel forever (I have no radar in vicinity and a couple of other 5GHz networks, all on channel 36).

However, on 3.0.0.4.386.44266, usually after the restart, the 5GHz network appears, but no devices can connect to it. After logging in to the router I see that the router selected channel 36 for some reason. In the log, I see the following messages that I think are related to the problem (never seen them on other firmware versions):

Code:
Jul 15 09:58:26 acsd: acs_candidate_score_intf(1080): eth6: intf check failed for chanspec: 0xe06a
Jul 15 09:58:26 acsd: acs_candidate_score_bgnoise(1500): eth6: bgnoise check failed for chanspec: 0xe06a
Jul 15 09:58:26 acsd: acs_candidate_score_txop(1758): eth6: txop check failed for chanspec: 0xe06a
Jul 15 09:58:26 acsd: acs_candidate_score_intf(1080): eth6: intf check failed for chanspec: 0xe16a
Jul 15 09:58:26 acsd: acs_candidate_score_bgnoise(1500): eth6: bgnoise check failed for chanspec: 0xe16a
Jul 15 09:58:26 acsd: acs_candidate_score_txop(1758): eth6: txop check failed for chanspec: 0xe16a
Jul 15 09:58:26 acsd: acs_candidate_score_intf(1080): eth6: intf check failed for chanspec: 0xe26a
Jul 15 09:58:26 acsd: acs_candidate_score_bgnoise(1500): eth6: bgnoise check failed for chanspec: 0xe26a
Jul 15 09:58:26 acsd: acs_candidate_score_txop(1758): eth6: txop check failed for chanspec: 0xe26a
Jul 15 09:58:26 acsd: acs_candidate_score_intf(1080): eth6: intf check failed for chanspec: 0xe36a
Jul 15 09:58:26 acsd: acs_candidate_score_bgnoise(1500): eth6: bgnoise check failed for chanspec: 0xe36a
Jul 15 09:58:26 acsd: acs_candidate_score_txop(1758): eth6: txop check failed for chanspec: 0xe36a
Jul 15 09:58:26 acsd: eth6: selected channel spec: 0xe06a (100/80)
Jul 15 09:58:26 acsd: eth6: Adjusted channel spec: 0xe06a (100/80)
Jul 15 09:58:26 acsd: eth6: selected channel spec: 0xe06a (100/80)
Jul 15 09:58:26 acsd: acs_set_chspec: 0xe06a (100/80) for reason APCS_INIT
Jul 15 09:58:26 acsd: acs_update_driver(441): acs update failed ret code: -16
Jul 15 09:58:26 acsd: acs_init_run(1065): eth6: update driver failed

Looks like the logic behind the automatic channel selection fails and causes the driver to fail. If I specify the channel 100 manually, everything works fine even after the restart, and there are no errors in the log. I've performed the hard reset twice on this firmware, but it does not help; rolling back to any previous version solves the problem. Interestingly, I found that similar messages were reported for GT-AX11000 and GT-AXE11000.

Has anyone run into the same problem with this firmware?

Same issue on 1 of my 2, AX56 in a Mesh
 
Besides, I'm getting the following new messages in the log on this firmware (never seen them before too):
Code:
Jul 21 21:12:10 rc_service: watchdog 1676:notify_rc firmware_webs_update
Jul 21 21:18:10 check_watchdog: [check_watchdog] restart watchdog for no heartbeat
Jul 21 21:18:10 rc_service: check_watchdog 1305:notify_rc restart_watchdog
Jul 21 21:20:10 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7282)]periodic_check AM 2:54
Jul 21 21:20:10 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7310)]fimrware update check first time
Jul 21 21:20:10 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7318)]notify_rc firmware_webs_update
Jul 21 21:20:10 rc_service: watchdog 2813:notify_rc firmware_webs_update
Jul 21 21:26:10 check_watchdog: [check_watchdog] restart watchdog for no heartbeat
Jul 21 21:26:10 rc_service: check_watchdog 1305:notify_rc restart_watchdog
Jul 21 21:28:10 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7282)]periodic_check AM 5:46
Jul 21 21:28:10 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7310)]fimrware update check first time
Jul 21 21:28:10 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7318)]notify_rc firmware_webs_update
Jul 21 21:28:10 rc_service: watchdog 3842:notify_rc firmware_webs_update
Jul 21 21:34:10 check_watchdog: [check_watchdog] restart watchdog for no heartbeat
Jul 21 21:34:10 rc_service: check_watchdog 1305:notify_rc restart_watchdog
Jul 21 21:36:10 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7282)]periodic_check AM 4:56
Jul 21 21:36:10 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7310)]fimrware update check first time
Jul 21 21:36:10 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7318)]notify_rc firmware_webs_update
Jul 21 21:36:10 rc_service: watchdog 4826:notify_rc firmware_webs_update
Jul 21 21:42:10 check_watchdog: [check_watchdog] restart watchdog for no heartbeat
Jul 21 21:42:10 rc_service: check_watchdog 1305:notify_rc restart_watchdog
Jul 21 21:44:10 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7282)]periodic_check AM 5:0
Jul 21 21:44:10 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7310)]fimrware update check first time
Jul 21 21:44:10 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7318)]notify_rc firmware_webs_update
Jul 21 21:44:10 rc_service: watchdog 5795:notify_rc firmware_webs_update

If I restart the router, they re-appear after about 8 hours of runtime. I'm a bit disappointed with how ASUS tests their firmware: auto channel selection does not work properly on 5GHz, the update service floods the log with the entries shown above, the Adaptive QOS still causes the "comm: tc tainted" messages, fonts on the AiMesh page are broken... Had to revert back to 3.0.0.4.386.42808.

UPDATE: No messages after reverting back to 3.0.0.4.386.42808 and updating again to 3.0.0.4.386.44266. Recent DNS outage may be the cause, who knows..
 
Last edited:
It has reappeared here too :(
Oh.. Looks like this issue does not appear when manual channel selection is used.

BTW, do you use Adaptive QOS? It also causes me headaches, since I often get the WARNING: CPU: 3 PID: 6200 at net/sched/sch_htb.c:568 htb_qlen_notify+0x78/0x80() messages in the log followed (maybe accidentally?) by the [check_watchdog] restart watchdog for no heartbeat messages.
 
With this firmware half of my devices cannot connect to their backend servers. That includes all Broadnet SP3S smart plugs and Pure digital radio. Very iffy fw! Had to rollback to 3.0.0.4.386_42808.

L
 

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