RT-AX86U with TUF-AX6000 as AiMesh node - Auto reboot when DHCP lease expires

[carlpea]

Hi all,

I have a odd issue that I've not been able to resolve over the past few days.

I've had an RT-AX86U for some time, running Merlin 388.2.

I've recently purchased a TUF-AX6000 which I'm using as a AiMesh node, connected on the WAN 2.5Gbps port, via a switch, to the RT-AX86U, which is used as the backhaul.

Every 24 hours the TUF-AX6000 is rebooting automatically (I know this by checking the uptime via SSH) and it matches with when the DHCP lease expires from the RT-AX86U.

It's a little frustrating as I have two wired devices connected to the TUF-AX6000 and they lose connection when the reboot occurs.

The logs at the time don't really show anything untoward, and I'm wondering if anyone has come across this before?

Log from RT-AX86U

Apr 17 10:13:35 wlceventd: wlceventd_proc_event(559): eth7: Assoc XX:XX:XX:XX:XX:XX, status: Successful (0), rssi:-51
Apr 17 11:08:37 wlceventd: wlceventd_proc_event(511): eth7: Disassoc XX:XX:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr 17 11:08:37 wlceventd: wlceventd_proc_event(511): eth7: Disassoc XX:XX:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr 17 11:09:20 acsd: acs_set_chspec: 0x1004 (4) for reason APCS_CSTIMER
Apr 17 11:09:20 acsd: eth6: selected_chspec is 0x1004 (4)
Apr 17 11:09:20 acsd: eth6: Adjusted channel spec: 0x1004 (4)
Apr 17 11:09:20 acsd: eth6: selected channel spec: 0x1004 (4)
Apr 17 11:09:20 acsd: eth6 Performing CSA on chspec 0x1004 (4)
Apr 17 11:10:14 wlceventd: wlceventd_proc_event(530): eth7: Auth XX:XX:XX:XX:XX:XX, status: Successful (0), rssi:0
Apr 17 11:10:14 wlceventd: wlceventd_proc_event(540): eth7: ReAssoc XX:XX:XX:XX:XX:XX, status: Successful (0), rssi:-59
Apr 17 11:42:47 acsd: acs_set_chspec: 0x1005 (5) for reason APCS_CSTIMER

I'll add the logs from the TUF-AX6000 if/when it happens again (I've reset it in the hope the issue resolves itself!

Thanks,

Carl.

 

[carlpea]

Looks like this was fixed in a recent firmware update (3.0.0.4.388_31927-g9b5e4ec).