What's new

AX68U rebooting randomly

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

xusco

Occasional Visitor
Hello there,

This is my first port although I was reading the forum regularly for the las 2 years. I need your help to read the logs to find the issue impacting my network.

I have an Asus AX68U running last Merlin firmware (3004.388.8_2) and 2 nodes in AiMesh: AC66U B1 and one ZenWifi XD4 Plus. I know that it is not the best to mix different hardware, but I want to use the equipment I already have. In the last couple of weeks, the main router is rebooting by itself and I have no idea why. The AC66U B1 is connected by an Ethernet backhaul, meanwhile the XD4 Plus is connected wirelessly because I can´t run a cable in the room. There is nothing special in the network, I´m running AiProtection (now disabled for troubleshooting) and few static IP addresses. This is what I found in the logs:


Sep 17 17:58:46 hostapd: eth5: STA 48:26:2c:e7:c1:be IEEE 802.11: associated

Sep 17 17:58:46 wlceventd: wlceventd_proc_event(722): eth5: Assoc 48:26:2C:E7:C1:BE, status: Successful (0), rssi:-69

Sep 17 17:58:46 hostapd: eth5: STA 48:26:2c:e7:c1:be RADIUS: starting accounting session F21ED18B3507E8C8

Sep 17 17:58:46 hostapd: eth5: STA 48:26:2c:e7:c1:be WPA: pairwise key handshake completed (RSN)

Sep 17 17:58:46 dnsmasq-dhcp[2073]: DHCPREQUEST(br0) 192.168.1.90 48:26:2c:e7:c1:be

Sep 17 17:58:46 dnsmasq-dhcp[2073]: DHCPACK(br0) 192.168.1.90 48:26:2c:e7:c1:be Mathias-Iphone

Sep 17 17:58:46 dnsmasq-dhcp[2073]: DHCPREQUEST(br0) 192.168.1.90 48:26:2c:e7:c1:be

Sep 17 17:58:46 dnsmasq-dhcp[2073]: DHCPACK(br0) 192.168.1.90 48:26:2c:e7:c1:be Mathias-Iphone

Sep 17 17:58:46 dnsmasq-dhcp[2073]: DHCPREQUEST(br0) 192.168.1.90 48:26:2c:e7:c1:be

Sep 17 17:58:46 dnsmasq-dhcp[2073]: DHCPACK(br0) 192.168.1.90 48:26:2c:e7:c1:be Mathias-Iphone

Sep 17 17:58:46 dnsmasq-dhcp[2073]: DHCPREQUEST(br0) 192.168.1.90 48:26:2c:e7:c1:be

Sep 17 17:58:46 dnsmasq-dhcp[2073]: DHCPACK(br0) 192.168.1.90 48:26:2c:e7:c1:be Mathias-Iphone

Sep 17 17:58:46 kernel: 48:26:2C:E7:C1:BE not mesh client, can't update it's ip

Sep 17 17:58:46 kernel: 48:26:2C:E7:C1:BE not mesh client, can't update it's ip

Sep 17 17:58:46 kernel: 48:26:2C:E7:C1:BE not mesh client, can't update it's ip

Sep 17 17:58:46 kernel: 48:26:2C:E7:C1:BE not mesh client, can't update it's ip

Sep 17 18:03:34 kernel: wl0: random key value: A53CA24501D3B46D084801E591DBDE5133758EFE6CBD07079472F7E5BC0669CA

Sep 17 18:03:34 wlceventd: wlceventd_proc_event(645): eth5: Deauth_ind 48:26:2C:E7:C1:BE, status: 0, reason: Station requesting (re)association is not authenticated with responding station (9), rssi:0

Sep 17 18:03:34 wlceventd: wlceventd_proc_event(662): eth5: Disassoc 48:26:2C:E7:C1:BE, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

Sep 17 18:03:34 hostapd: eth5: STA 48:26:2c:e7:c1:be IEEE 802.11: disassociated

Sep 17 18:03:37 kernel: 48:26:2C:E7:C1:BE not mesh client, can't delete it

Sep 17 18:06:34 kernel: wl0: random key value: F90AF199B330277210FF01C499A9B6ED61F8DE592ED206B3F62A1A741073935B

Sep 17 18:06:34 wlceventd: wlceventd_proc_event(662): eth5: Disassoc 48:55:19:18:12:EB, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

Sep 17 18:06:34 hostapd: eth5: STA 48:55:19:18:12:eb IEEE 802.11: disassociated

Sep 17 18:06:34 hostapd: eth5: STA 48:55:19:18:12:eb IEEE 802.11: disassociated

Sep 17 18:06:34 wlceventd: wlceventd_proc_event(662): eth5: Disassoc 48:55:19:18:12:EB, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

May 5 07:05:04 syslogd started: BusyBox v1.25.1

May 5 07:05:04 crashlog: LOG


What can cause the reboot? I have no idea how the read the logs. It seems that the node with the MAC address 48:26:2C:E7:C1:BE was disconnected, but the AC66U B1 and the XD4 Plus have different MAC addresses. If it refers to eth5, could be the port where the AC66U B1 I connected to, so I unplugged it now for troubleshooting to see what happens. I also disabled AiProtection and didn’t make any difference. The problem is that reboots are quite random. They happen every day, usually in less than 24 hours. Now the system is stable for about 17 hours. I added the XD4 Plus about 10 days ago via wifi and I don´t know if it can be related somehow. The truth is that it seems to happen more often now.

Thank you in advance,
 
If you have an external drive connected, unmount it from the UI and then pull the power cord out of the wall for 30+ seconds.
If either of the Wifi radios are having issues this will fully restart them, where a reboot does not. Merlin gave me this advice before when my 5Ghz kept crashing and it got it to stop.

The only reference I found to a crash log in my syslog was there one being located on /jffs/crashlog.log

If you can SSH into the router and see if that file is there, that might have more clues.

If you don't know how to use SSH then maybe WinSCP would be better, you set it up like this with your router IP, admin user/pass. It gives you a file explorer type view.

I think this should work out of the box, unless I had to install something in entware to allow this to work.

1726659657348.png
 
Thank you @jtp10181,

I was checking the /jffs and there is no a crashlog.log file or something similar. There is the syslog.log file which is basically the same logs than in the router GUI.

Not sure if the problem is related with the wifi, but always when I have such problems disconnect the router and nodes for 3 -4 minutes to be sure that everything is deleted.
 
I found something interesting (for me):

Sep 17 18:03:34 wlceventd: wlceventd_proc_event(662): eth5: Disassoc 48:26:2C:E7:C1:BE, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

Sep 17 18:03:34 hostapd: eth5: STA 48:26:2c:e7:c1:be IEEE 802.11: disassociated

Sep 17 18:03:37 kernel: 48:26:2C:E7:C1:BE not mesh client, can't delete it

This is my son´s iPhone which is connected to the XD4 Plus (wifi backhaul). The node iftself is up but the client is disconnected for some reason. Let assume that he left the room and this is the normal behavior. Later on there is another disconnection:

Sep 17 18:06:34 wlceventd: wlceventd_proc_event(662): eth5: Disassoc 48:55:19:18:12:EB, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

Sep 17 18:06:34 hostapd: eth5: STA 48:55:19:18:12:eb IEEE 802.11: disassociated

Sep 17 18:06:34 hostapd: eth5: STA 48:55:19:18:12:eb IEEE 802.11: disassociated

Sep 17 18:06:34 wlceventd: wlceventd_proc_event(662): eth5: Disassoc 48:55:19:18:12:EB, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

This is a smartplug connected to the AC66U B1 (Ethernet backhaul). This device obviously didn´t leave the room where is plugged so, why it was dsiconnected at the same time? So far seems a wifi issue but then the main router was rebooted. Could the reboot be caused by the wifi issue? As you can see I have no idea how this things work but I need to find the root cause to solve as I´m working from home.

An obvious advice is to make a full reset and start from scratch, but it´s not possible because I´m working from home and I could do it only during the weekend when all the family is at home and they will be not happy at all... I have about 20 smart devices and everything will be down during the full reset, so I consider this as the last option.

Thank you for you patience
 
Funny, the router was rebooted again meanwhile sending the previous post:

Sep 18 16:51:29 wlceventd: wlceventd_proc_event(685): eth5: Auth 06:3B:AB:4A:EF:BA, status: Successful (0), rssi:0
Sep 18 16:51:29 hostapd: eth5: STA 06:3b:ab:4a:ef:ba IEEE 802.11: associated
Sep 18 16:51:29 wlceventd: wlceventd_proc_event(722): eth5: Assoc 06:3B:AB:4A:EF:BA, status: Successful (0), rssi:-73
Sep 18 16:51:29 hostapd: eth5: STA 06:3b:ab:4a:ef:ba RADIUS: starting accounting session 8B674CEF5E74A8A5
Sep 18 16:51:29 hostapd: eth5: STA 06:3b:ab:4a:ef:ba WPA: pairwise key handshake completed (RSN)
Sep 18 16:51:29 dnsmasq-dhcp[2040]: DHCPDISCOVER(br0) 06:3b:ab:4a:ef:ba
Sep 18 16:51:29 dnsmasq-dhcp[2040]: DHCPOFFER(br0) 192.168.1.61 06:3b:ab:4a:ef:ba
Sep 18 16:51:29 dnsmasq-dhcp[2040]: DHCPDISCOVER(br0) 06:3b:ab:4a:ef:ba
Sep 18 16:51:29 dnsmasq-dhcp[2040]: DHCPOFFER(br0) 192.168.1.61 06:3b:ab:4a:ef:ba
Sep 18 16:51:29 dnsmasq-dhcp[2040]: DHCPDISCOVER(br0) 06:3b:ab:4a:ef:ba
Sep 18 16:51:29 dnsmasq-dhcp[2040]: DHCPOFFER(br0) 192.168.1.61 06:3b:ab:4a:ef:ba
Sep 18 16:51:29 dnsmasq-dhcp[2040]: DHCPDISCOVER(br0) 06:3b:ab:4a:ef:ba
Sep 18 16:51:29 dnsmasq-dhcp[2040]: DHCPOFFER(br0) 192.168.1.61 06:3b:ab:4a:ef:ba
Sep 18 16:51:30 dnsmasq-dhcp[2040]: DHCPREQUEST(br0) 192.168.1.61 06:3b:ab:4a:ef:ba
Sep 18 16:51:30 dnsmasq-dhcp[2040]: DHCPACK(br0) 192.168.1.61 06:3b:ab:4a:ef:ba realme-8
Sep 18 16:51:30 dnsmasq-dhcp[2040]: DHCPREQUEST(br0) 192.168.1.61 06:3b:ab:4a:ef:ba
Sep 18 16:51:30 dnsmasq-dhcp[2040]: DHCPACK(br0) 192.168.1.61 06:3b:ab:4a:ef:ba realme-8
Sep 18 16:51:30 dnsmasq-dhcp[2040]: DHCPREQUEST(br0) 192.168.1.61 06:3b:ab:4a:ef:ba
Sep 18 16:51:30 dnsmasq-dhcp[2040]: DHCPACK(br0) 192.168.1.61 06:3b:ab:4a:ef:ba realme-8
Sep 18 16:51:30 dnsmasq-dhcp[2040]: DHCPREQUEST(br0) 192.168.1.61 06:3b:ab:4a:ef:ba
Sep 18 16:51:30 dnsmasq-dhcp[2040]: DHCPACK(br0) 192.168.1.61 06:3b:ab:4a:ef:ba realme-8
Sep 18 16:52:55 dnsmasq-dhcp[2040]: DHCPREQUEST(br0) 192.168.1.61 06:3b:ab:4a:ef:ba
Sep 18 16:52:55 dnsmasq-dhcp[2040]: DHCPACK(br0) 192.168.1.61 06:3b:ab:4a:ef:ba realme-8
Sep 18 16:52:55 dnsmasq-dhcp[2040]: DHCPREQUEST(br0) 192.168.1.61 06:3b:ab:4a:ef:ba
Sep 18 16:52:55 dnsmasq-dhcp[2040]: DHCPACK(br0) 192.168.1.61 06:3b:ab:4a:ef:ba realme-8
Sep 18 16:53:11 wlceventd: wlceventd_proc_event(645): eth5: Deauth_ind 06:3B:AB:4A:EF:BA, status: 0, reason: Disassociated due to inactivity (4), rssi:-94
Sep 18 16:53:11 hostapd: eth5: STA 06:3b:ab:4a:ef:ba IEEE 802.11: disassociated
Sep 18 16:53:11 hostapd: eth5: STA 06:3b:ab:4a:ef:ba IEEE 802.11: disassociated
Sep 18 16:53:11 wlceventd: wlceventd_proc_event(645): eth5: Deauth_ind 06:3B:AB:4A:EF:BA, status: 0, reason: Previous authentication no longer valid (2), rssi:-94
Sep 18 16:53:12 kernel: wl0: random key value: 440345642EB9D9D12DEF028F1A9EBD3C66FE16F19CBA03678F1CB2B07FB04435
Sep 18 16:53:12 hostapd: eth5: STA 06:3b:ab:4a:ef:ba IEEE 802.11: disassociated
Sep 18 16:53:12 wlceventd: wlceventd_proc_event(662): eth5: Disassoc 06:3B:AB:4A:EF:BA, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Sep 18 16:53:14 wlceventd: wlceventd_proc_event(685): eth5: Auth 06:3B:AB:4A:EF:BA, status: Successful (0), rssi:0
Sep 18 16:53:14 kernel: br0: received packet on eth5.0 with own address as source address
Sep 18 16:53:14 kernel: br0: received packet on eth5.0 with own address as source address
Sep 18 16:53:14 kernel: br0: received packet on eth5.0 with own address as source address
Sep 18 16:53:14 kernel: br0: received packet on eth5.0 with own address as source address
Sep 18 16:53:14 hostapd: eth5: STA 06:3b:ab:4a:ef:ba IEEE 802.11: associated
Sep 18 16:53:14 wlceventd: wlceventd_proc_event(695): eth5: ReAssoc 06:3B:AB:4A:EF:BA, status: Successful (0), rssi:-73
Sep 18 16:53:14 hostapd: eth5: STA 06:3b:ab:4a:ef:ba RADIUS: starting accounting session 67E1D9953FCFF946
Sep 18 16:53:14 hostapd: eth5: STA 06:3b:ab:4a:ef:ba WPA: pairwise key handshake completed (RSN)
Sep 18 16:54:42 kernel: D8:1F:12:62:28:BA not mesh client, can't delete it
Sep 18 16:58:31 dnsmasq-dhcp[2040]: DHCPREQUEST(br0) 192.168.1.90 48:26:2c:e7:c1:be
Sep 18 16:58:31 dnsmasq-dhcp[2040]: DHCPACK(br0) 192.168.1.90 48:26:2c:e7:c1:be Mathias-Iphone
Sep 18 16:58:31 dnsmasq-dhcp[2040]: DHCPREQUEST(br0) 192.168.1.90 48:26:2c:e7:c1:be
Sep 18 16:58:31 dnsmasq-dhcp[2040]: DHCPACK(br0) 192.168.1.90 48:26:2c:e7:c1:be Mathias-Iphone
Sep 18 16:58:31 dnsmasq-dhcp[2040]: DHCPREQUEST(br0) 192.168.1.90 48:26:2c:e7:c1:be
Sep 18 16:58:31 dnsmasq-dhcp[2040]: DHCPACK(br0) 192.168.1.90 48:26:2c:e7:c1:be Mathias-Iphone
Sep 18 16:58:31 dnsmasq-dhcp[2040]: DHCPREQUEST(br0) 192.168.1.90 48:26:2c:e7:c1:be
Sep 18 16:58:31 dnsmasq-dhcp[2040]: DHCPACK(br0) 192.168.1.90 48:26:2c:e7:c1:be Mathias-Iphone
Sep 18 16:58:31 kernel: 20:28:BC:99:F9:D4 not mesh client, can't delete it
Sep 18 17:02:17 dnsmasq-dhcp[2040]: DHCPREQUEST(br0) 192.168.1.224 1c:90:ff:4e:00:04
Sep 18 17:02:17 dnsmasq-dhcp[2040]: DHCPACK(br0) 192.168.1.224 1c:90:ff:4e:00:04
Sep 18 17:09:12 hostapd: eth5: STA 24:4b:fe:92:10:31 WPA: group key handshake completed (RSN)
Sep 18 17:09:12 hostapd: eth5: STA ce:7f:54:75:84:f8 WPA: group key handshake completed (RSN)
Sep 18 17:09:12 hostapd: eth5: STA 1c:90:ff:4e:00:04 WPA: group key handshake completed (RSN)
Sep 18 17:09:12 hostapd: eth5: STA d8:1f:12:66:13:7d WPA: group key handshake completed (RSN)
Sep 18 17:09:12 hostapd: wl0.1: STA d8:1f:12:62:28:ba WPA: group key handshake completed (RSN)
Sep 18 17:09:12 hostapd: eth6: STA c2:7f:54:75:84:f8 WPA: group key handshake completed (RSN)
Sep 18 17:09:12 hostapd: eth5: STA 06:3b:ab:4a:ef:ba WPA: group key handshake completed (RSN)
Sep 18 17:09:12 hostapd: eth6: STA 24:4b:fe:92:10:34 WPA: group key handshake completed (RSN)
Sep 18 17:09:12 hostapd: eth6: STA 2e:c8:4a:81:f6:58 WPA: group key handshake completed (RSN)
May 5 07:05:04 syslogd started: BusyBox v1.25.1
May 5 07:05:04 crashlog: LOG
 
The disassociated logs are pretty normal. Could be a device switching APs (nodes) or leaving the wifi range.

That other thread they are suspecting it might be something with the Trend Micro stuff.

If you go to Administration > Policy then you can revoke the Trend Micro agreement. This will fully shut down the entire TM engine and prevent it from running. It may disable a few features you had enabled. If you go to enable something again it will make you agree again so you will know if you are enabling it again. Leave it off for a bit as a test.

They also had luck with downgrading to the initial 388.8 release (not the newer _2 version)

1726746377513.png
 
Thank you @wuwentao, I don’t have the AX86U but the AX68U. Anyway, I had the same issues with previous firmwares and I can’t remember an older one to be more stable. I’m using the 388.8_2 from the 1st day and didn’t have such issues. For several months it happened Avery 7 -10 days, which dint bother me. The problem now is that I’m working from home and crashes are happening more often. Maybe somebody with the AX68U can tell me which firmware seems to be more stable just to try it.

And thank you as well @jtp10181. As I said before, I disabled TrendMicro features and dint make any difference, maybe router was crashing after 25 hours instead of 17, who knows, but didn’t improve the overall stability.

Is there any post / web where I can find the basics to understand the logs? It’s the 1st time in my life that I have to read them.
 
It's one thing disabling TM features. It's another withdrawing consent and totally shutting down the TM engine. Of course, a reboot is necessary.
Just my experience.
 
Yes, I was withdrawing consent and totally shutting down the TM engine as part of the troubleshooting process and made no difference.

And I still don’t understand why devices were disconnecting from Wi-Fi, the phones and tablets it’s easy to understand, but the smart plugs? They didn’t move unless there are paranormal issues at home… And why was the router crashing? Just because some devices lose connectivity?
 
I just realized that when connecting the XD4, wire or wireless, the memory available decreases by 70Mb. Could be this the problem? What should I look for in the logs to confirm if the router runs out of memory?

As you can see, I’m completely lost as I’m new to this network world.

Thanks again for your patience and support
 
I performed a factory reset deleting the /jffs, and after few minutes, I also performed the WPS reset and started setting up everything manually. I only set the wifi password and 4 static IP’s to keep my solar system and Home Assistant working properly. I didn’t change anything in the wifi settings, just added the nodes again to have full coverage in the house…

And the router crashed after 2 hours!!!!

I attached the syslog in case somebody can have a look and provide some light….
 

Attachments

  • syslog (1).txt
    711.5 KB · Views: 12
Last edited:
Okay, so I've not got the time to do too much of a deep dive but: The events posted do not appear to be a router "reboot", and one of the "misbehaving" devices appears to be "Mathias-Iphone", not the router or one of it's satellites.

*I'm so very prepared to be wrong here, so apologies in advance!
 
Thanks again for trying to help. I’m still completely lost. I can understand that my son’s iPhone is roaming all the time, but the node where he is connected to appears disconnected in the GUI, then other devices connected to another node starts disconnecting as well, and then the voip call I’m having is down. And then, checking the GUI, the only thing I can do due to my lack of knowledge, shows that the router rebooted few seconds before, just when I lose the voip call.

I did a factory reset, downgraded to previous Merlín firmwares and the official ones, did another factory reset after installing the firmware, srt up manually few things, and the issue appears randomly again. The maximum time without reboots is about 15 hours. And I didn’t make any change in my network when the issue started few weeks ago. Could be a hardware issue?

I was in touch with Asus support and they told my to follow up with the dealer and this is another interesting thing. I registered the router in Asus webpage and I still have 5 months warranty (originally 3 years), but according to the invoice I have only 2 years warranty, so it expired 7 months ago. I really don’t know what to think about Asus and the way they deal with such issues.
 
Okay, so I've not got the time to do too much of a deep dive but: The events posted do not appear to be a router "reboot", and one of the "misbehaving" devices appears to be "Mathias-Iphone", not the router or one of it's satellites.

its in the log a few times, but its not not correlating to the logged rc_notify reboots, nor the sole case where it started dirty.

D8:1F:12:66:13:7D is though.
 
its in the log a few times, but its not not correlating to the logged rc_notify reboots, nor the sole case where it started dirty.

D8:1F:12:66:13:7D is though.

Thank you for checking this issue for me but I can’t understand what you mean in this sentence. Was the router rebooting as I said? Is the rc_notify showing a Wi-Fi reboot or router reboot?
 
its a full system reboot, it unloads all services and then unmounts the nvram in 3 of the 4 cases, with the last being an actual crash.
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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