AiMesh Node going OFFLINE after a few weeks

[Pergola Fabio]

ok, gonna update the nodes to stock instead of merlin , lets see what happens coming days/weeks.... for now i leave main router on merlin, only nodes on stock

 

[LimJK]

Again, offline , if i do the command below on main router ,i still see it listed ... So why is it offline ?? It happened again after about a week uptime


nvram get cfg_device_list

@LimJK ..

Have you resolved it? I see exactly the same behaviour... When it's offline, i see also indeed a lot of DHCP request every 30 sec for that node... I can still ping it, i can still ssh it... Everything works like it should , but seems it's just offline state for the main router... And wifi is complete gone on that node... While ethernet works... Looks like its locked..
Always happens after about a week ...

Only thing to resolve it , is to reboot the node

Hi, Pergola Fabio,

My original post was 15th Nov 2018 (just under 3 years ago), I cannot remember which Firmware Version(s) I used at that point. I thought context is different and did not get involved in the new discussion in this very, very old thread. Since you ask me, this is what I can share with you, hope that it is useful for you.

My configuration:

• AiMesh Router: AX88U 386.3_2 +
• 2 x AiMesh Nodes: AC86U 3.0.0.4_386_44470-g53bccb8
• Wired Backhaul (Priority:"Auto"), Asus GX-U1051 5-Port Gigabit Switch from Router to Nodes

I experienced problems with WiFi 2.4GHz band for my RT-AC86U nodes that degraded from 3 streams to 1 stream after Factory reset.

• However, I found a workaround for my case, I SSH to the offending Node and do service restart_wireless, after a few times over a few days somehow it stays with 3 streams, thus, resolved my issue. I cannot explain this in a logical manner, but it works for me over many versions of firmware (Stock or Merlin) over a year.
• I monitor this degradation with WiFi Explorer App on my MacBookPro, I know of no other ways to monitor the number streams on the AiMesh Router / Node. Without the streams information you can only feel that speed is much slower on your devices.

As far as AiMesh Nodes getting disconnected:

• for my case it was dust / oxidation on the RJ45 Connectors and/or cable issues. My workaround is to use contact cleaners spray and fine brush to clean both the male and female contact points and visually observe that the contact points are clean. By the way I use only CAT 6 or CAT 7 cables
• Few years back when Asus first introduced AiMesh 1.0, I found that certain switches may not be supported, I replaced a old Cisco switch with a Asus switch

My suggestion is to try to start with “default” NVRAM Settings for AiMesh (eg. leave Backhaul priority as "Auto") and WiFi (eg. I used Merlin FW default settings, with Fix Channel and Bandwidth);

(1) I have no problem for over 24 days

(2) No AiMesh Nodes disconnected for over 24 days

(3) My Wifi for both 2.4GHz and 5GHz works fine with no disconnect for over 24 days

Hope, it give you some thing to compare, Hope you find your solution. Cheers

 

[Pergola Fabio]

hi @LimJK , thnx for feedback
i have installed yesterday also stock on the nodes instead of merlin , lets hope that the firmware issue was the culprit
Dust,,hmm dont think so... when node is offline, all LAN connected devices are still working, only the wifi is complete gone on the node, lan still works, i can even connect to it with SSH
Also switch is not the issue, all nodes are directly connected to the main ac88u

so that stream you are talking about looks interesting, how do you see how many streams are used?

 

[Pergola Fabio]

hey @LimJK

today i saw 1 node just rebooting, not sure why, dont know if it happened before when i was running merlin on the nodes ... now i use stock
in logs i saw again a lot of dhcp requests , and then it rebooted ... gonna keep on eye on it ... but maybe now it reboots itself when its somekind of stuck?

before the dhcp requests keep on coming ...

here you see the reboot after about 10 min of dhcp requests, before this never stopped

Sep 1 20:44:24 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:44:57 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:44:57 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:45:29 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:45:29 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:46:01 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:46:01 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:46:34 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:46:34 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:47:06 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.69 00:22:6c:14:cd:5c
Sep 1 20:47:06 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.69 00:22:6c:14:cd:5c Luidspeker
Sep 1 20:47:06 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:47:06 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:47:39 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:47:39 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:48:11 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:48:11 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:48:43 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:48:43 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:49:16 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:49:16 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:49:48 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:49:48 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:50:20 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:50:20 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:50:53 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:50:53 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:51:25 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:51:25 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:51:44 syslog: wlceventd_proc_event(527): eth1: Auth 7CD:90:CC:EC:23, status: Successful (0), rssi:0
Sep 1 20:51:45 syslog: wlceventd_proc_event(556): eth1: Assoc 7CD:90:CC:EC:23, status: Successful (0), rssi:0
Sep 1 20:52:21 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.197 26:67:a5:f5:96:97
Sep 1 20:52:21 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.197 26:67:a5:f5:96:97 OnePlus-6T
Sep 1 20:52:23 kernel: device br0 entered promiscuous mode
Sep 1 20:52:26 dnsmasq-dhcp[29599]: DHCPDISCOVER(br0) 84:c0:ef:25:77:42
Sep 1 20:52:26 dnsmasq-dhcp[29599]: DHCPOFFER(br0) 192.168.0.60 84:c0:ef:25:77:42
Sep 1 20:52:26 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.60 84:c0:ef:25:77:42
Sep 1 20:52:26 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.60 84:c0:ef:25:77:42 samsung_1
Sep 1 20:52:31 kernel: device br0 left promiscuous mode
Sep 1 20:52:31 kernel: device br0 entered promiscuous mode
Sep 1 20:52:40 dnsmasq-dhcp[29599]: DHCPDISCOVER(br0) 0c:9d:92:46:4e:a0
Sep 1 20:52:40 dnsmasq-dhcp[29599]: DHCPOFFER(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:52:40 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:52:40 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:52:48 dnsmasq-dhcp[29599]: DHCPREQUEST(br0) 192.168.0.3 0c:9d:92:46:4e:a0
Sep 1 20:52:48 dnsmasq-dhcp[29599]: DHCPACK(br0) 192.168.0.3 0c:9d:92:46:4e:a0 rt-ac-86u2
Sep 1 20:53:33 kernel: device br0 left promiscuous mode
Sep 1 20:54:29 syslog: wlceventd_proc_event(491): eth2: Deauth_ind 7C9:5C:7A:A5:E4, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Sep 1 20:54:29 syslog: wlceventd_proc_event(508): eth2: Disassoc 7C9:5C:7A:A5:E4, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

 

[Pergola Fabio]

fingers crossed, but looks more stable now after stock firmware