HW issue on RT-AX58U

[Ola Malmstrom]

I have a RT-AX58U configured as an AP with ethernet backhaul to my Zenwifi XT12 Pro router. It is located in a remote spot with very poor coverage. Power setting is on min to avoid too much overlap. There are different SSIDs for 2.4 and 5 GHz. The AP is running on the latest stock FW.

This has worked flawlessly for months now.

A few days ago my phone and PC couldn't connect to the AX58U. When checking with my tools (analiti, WiFiman and WiFi Analyzer) I couldn't find the 5GHz beam at all.

So I checked the log file and found a lot of mysterious entries. This is just an example. I don't know when the issue occurred. The log file is filled with entries as below:

Feb 9 22:42:20 kernel: Set wpa_cap for preauth error -1
Feb 9 22:42:20 kernel: Beacon set security failed
Feb 9 22:42:20 kernel: ADD/SET beacon failed
Feb 9 22:42:20 kernel: Set wpa_cap for preauth error -1
Feb 9 22:42:20 kernel: Beacon set security failed
Feb 9 22:42:20 kernel: ADD/SET beacon failed
Feb 9 22:42:25 kernel: CSIMON: CSIMON[1.1.0] Initialization
Feb 9 22:42:25 kernel: CSIMON: M2M usr already registered ...
Feb 9 22:42:25 kernel: CSIMON: CSIMON[1.1.0] Initialization
Feb 9 22:42:25 kernel: CSIMON: M2M usr already registered ...
Feb 9 22:42:25 kernel: Set wpa_cap for preauth error -1
Feb 9 22:42:25 kernel: Beacon set security failed
Feb 9 22:42:25 kernel: ADD/SET beacon failed
Feb 9 22:42:25 kernel: Set wpa_cap for preauth error -1
Feb 9 22:42:25 kernel: Beacon set security failed
Feb 9 22:42:25 kernel: ADD/SET beacon failed
Feb 9 22:42:30 kernel: CSIMON: CSIMON[1.1.0] Initialization
Feb 9 22:42:30 kernel: CSIMON: M2M usr already registered ...
Feb 9 22:42:30 kernel: CSIMON: CSIMON[1.1.0] Initialization
Feb 9 22:42:30 kernel: CSIMON: M2M usr already registered ...
Feb 9 22:42:30 kernel: Set wpa_cap for preauth error -1
Feb 9 22:42:30 kernel: Beacon set security failed
Feb 9 22:42:30 kernel: ADD/SET beacon failed
Feb 9 22:42:30 kernel: Set wpa_cap for preauth error -1

So I rebooted the RT-AX58U and after a couple of minutes everything worked as before. Roaming between my APs and the router works fine, and all error messages above have disappeared.

Feb 9 22:59:42 rc_service: httpd 2314:notify_rc reboot
Feb 9 22:59:44 iTunes: daemon is stoped
Feb 9 22:59:44 FTP Server: daemon is stopped
Feb 9 22:59:44 Samba Server: smb daemon is stopped
Feb 9 22:59:44 Timemachine: daemon is stoped
Feb 9 22:59:44 WEBDAV Server: daemon is stoped
Feb 9 22:59:44 WEBDAV Server: daemon is stoped
Feb 9 22:59:44 Mastiff: Got SIGTERM
Feb 9 22:59:47 iTunes: daemon is stoped
Feb 9 22:59:47 FTP Server: daemon is stopped
Feb 9 22:59:47 Samba Server: smb daemon is stopped
Feb 9 22:59:47 Timemachine: daemon is stoped
Feb 9 22:59:47 disk_monitor: Finish
Feb 9 22:59:48 ahs: ===Terminate ahs daemon===
Feb 9 22:59:50 kernel: port_generic_stop 572 skip turnning off power on eth0 here
Feb 9 22:59:50 kernel: port_generic_stop 572 skip turnning off power on eth1 here
Feb 9 22:59:50 kernel: [dev_kfree_skb_thread_wait] Waited and freed all pkts
Feb 9 22:59:50 kernel: [dev_kfree_skb_thread_wait] Waited and freed all pkts
May 5 07:05:02 kernel: klogd started: BusyBox v1.24.1 (2023-09-14 10:07:45 CST)
May 5 07:05:02 kernel: Linux version 4.19.183 (defjovi@X15639-PLX) (g

The AP now seems to work as before - but Do I have a HW error of some kind?

However when I looked through the log file, I also found this:

May 5 07:05:02 kernel: --- Step 0 powerup/reset sequence of core #0 at address 6
May 5 07:05:02 kernel: INFO _merlin28_core_power_op(): START powering up Merlin Core #0 with PRTAD = 6, ln_offset_stap = 0
May 5 07:05:02 kernel: INFO _merlin28_core_power_op(): Disable IDDQ
May 5 07:05:02 kernel: INFO _merlin28_core_power_op(): Provide a delay of 1ms after IDDQ is de-asserted
May 5 07:05:02 kernel: INFO _merlin28_core_power_op(): Disable serdes_reset and refclk_reset
May 5 07:05:02 kernel: INFO _merlin28_core_power_op: assert IDDQ|RESET|REFCLK_RESET to power down Serdes
May 5 07:05:02 kernel: INFO _merlin28_core_power_op(): START powering up Merlin Core #0 with PRTAD = 6, ln_offset_stap = 0
May 5 07:05:02 kernel: INFO _merlin28_core_power_op(): Disable IDDQ
May 5 07:05:02 kernel: INFO _merlin28_core_power_op(): Provide a delay of 1ms after IDDQ is de-asserted
May 5 07:05:02 kernel: INFO _merlin28_core_power_op(): Disable serdes_reset and refclk_reset
May 5 07:05:02 kernel: Toggle Serdes Core #0 LANE #0 PMD and uC reset.
May 5 07:05:02 kernel: INFO merlin28_core_init(): END. Core #0 with PRTAD = 6, ln_offset_stap = 0
May 5 07:05:02 kernel: MerlinSupport::merlin28_powerdn_lane(): powering down core #0x0 lane #0x0
May 5 07:05:02 kernel: MerlinSupport::merlin28_powerdn_lane(): powering down core #0x0 lane #0x1
May 5 07:05:02 kernel: merlin28_serdes_init(): Step 4.a Set uc_active = 1
May 5 07:05:02 kernel: merlin28_serdes_init(): Step 4. Assert micro reset
May 5 07:05:02 kernel: merlin28_serdes_init(): Step 4.a.2 Micro code load and verify
May 5 07:05:02 kernel: merlin28_load_firmware(): INFO: Start to download firmware to core # 0
May 5 07:05:02 kernel: merlin28_load_firmware(): Checking init_done initial value passed...
May 5 07:05:02 kernel: merlin28_load_firmware(): Checking init_done passed ...
May 5 07:05:02 kernel: merlin28_load_firmware(): begin writing firmware to the program ram ...
May 5 07:05:02 kernel: #################################################################################
May 5 07:05:02 kernel: merlin28_load_firmware(): end writing firmware to the program ram ...
May 5 07:05:02 kernel: Micro code read back verification succeeded
May 5 07:05:02 kernel: merlin28_serdes_init(): Step 4.b De-assert micro reset

Since the AP is running stock FW, why does the log file mention merlin?

 

[ColinTaylor]

The AP now seems to work as before - but Do I have a HW error of some kind?

Quite possibly. Keep an eye on it to see if it reoccurs. Otherwise it might just have been a one-off glitch.

Since the AP is running stock FW, why does the log file mention merlin?

That "merlin" has nothing to do with Merlin firmware. It just happens to be the name of a Broadcom chipset function. Ignore it.

 

[Ripshod]

Since the AP is running stock FW, why does the log file mention merlin?

Because it's a two way street. Merlin uses Asus code, Asus use Merlin's code (particularly the fixes).

 

[ColinTaylor]

Because it's a two way street. Merlin uses Asus code, Asus use Merlin's code (particularly the fixes).

That message has nothing to do with Merlin's firmware.

 

[Ola Malmstrom]

Thank you! I will keep an eye on this and hope it doesn't occur again.