AiMesh Node Dropping with Strange DHCP Entries

[fizix610]

Greetings! I have two RT-AC68U routers in an AiMesh configuration. Both running 386.1. The AiMesh node seems to drop off a few times per day despite reporting "Great" connection quality prior to dropping off. I also noticed some very strange DHCP activity coming from the node (MAC 1C:B7:2C:C5:16:E9) shortly before dropping off. Here is my log during that timeframe:

Feb 16 11:37:44 dnsmasq-dhcp[1659]: DHCPDISCOVER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:37:44 dnsmasq-dhcp[1659]: DHCPOFFER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:07 dnsmasq-dhcp[1659]: DHCPDISCOVER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:07 dnsmasq-dhcp[1659]: DHCPOFFER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:09 dnsmasq-dhcp[1659]: DHCPDISCOVER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:09 dnsmasq-dhcp[1659]: DHCPOFFER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:12 dnsmasq-dhcp[1659]: DHCPDISCOVER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:12 dnsmasq-dhcp[1659]: DHCPOFFER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:16 dnsmasq-dhcp[1659]: DHCPDISCOVER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:16 dnsmasq-dhcp[1659]: DHCPOFFER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:33 syslog: wlceventd_proc_event(490): eth1: Deauth_ind E8:6F:38:64:33:8B, status: 0, reason: Disassociated due to inactivity (4), rssi:0
Feb 16 11:38:39 dnsmasq-dhcp[1659]: DHCPDISCOVER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:39 dnsmasq-dhcp[1659]: DHCPOFFER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:41 dnsmasq-dhcp[1659]: DHCPDISCOVER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:41 dnsmasq-dhcp[1659]: DHCPOFFER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:44 dnsmasq-dhcp[1659]: DHCPDISCOVER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:44 dnsmasq-dhcp[1659]: DHCPOFFER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:48 dnsmasq-dhcp[1659]: DHCPDISCOVER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:38:48 dnsmasq-dhcp[1659]: DHCPOFFER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:39:11 dnsmasq-dhcp[1659]: DHCPDISCOVER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:39:11 dnsmasq-dhcp[1659]: DHCPOFFER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:39:13 dnsmasq-dhcp[1659]: DHCPDISCOVER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:39:13 dnsmasq-dhcp[1659]: DHCPOFFER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:39:17 dnsmasq-dhcp[1659]: DHCPDISCOVER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:39:17 dnsmasq-dhcp[1659]: DHCPOFFER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:39:20 dnsmasq-dhcp[1659]: DHCPDISCOVER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:39:20 dnsmasq-dhcp[1659]: DHCPOFFER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:39:32 syslog: wlceventd_proc_event(507): eth1: Disassoc 1C:B7:2C:C5:16:E9, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 16 11:39:33 syslog: wlceventd_proc_event(507): eth2: Disassoc 1C:B7:2C:C5:16:EC, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 16 11:39:35 kernel: br0: port 5(wds0.1) entering forwarding state
Feb 16 11:39:35 kernel: device wds0.1 left promiscuous mode
Feb 16 11:39:35 kernel: br0: port 5(wds0.1) entering disabled state
Feb 16 11:39:35 syslog: wlceventd_proc_event(526): eth1: Auth 1C:B7:2C:C5:16:E9, status: Successful (0), rssi:0
Feb 16 11:39:35 syslog: wlceventd_proc_event(555): eth1: Assoc 1C:B7:2C:C5:16:E9, status: Successful (0), rssi:0
Feb 16 11:39:35 syslog: wlceventd_proc_event(526): eth2: Auth 1C:B7:2C:C5:16:EC, status: Successful (0), rssi:0
Feb 16 11:39:35 kernel: br0: port 4(wds1.3) entering forwarding state
Feb 16 11:39:35 kernel: device wds1.3 left promiscuous mode
Feb 16 11:39:35 kernel: br0: port 4(wds1.3) entering disabled state
Feb 16 11:39:35 syslog: wlceventd_proc_event(555): eth2: Assoc 1C:B7:2C:C5:16:EC, status: Successful (0), rssi:0
Feb 16 11:39:35 syslog: wlceventd_proc_event(507): eth2: Disassoc 1C:B7:2C:C5:16:EC, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 16 11:39:36 kernel: device wds0.1 entered promiscuous mode
Feb 16 11:39:36 kernel: br0: topology change detected, propagating
Feb 16 11:39:36 kernel: br0: port 4(wds0.1) entering forwarding state
Feb 16 11:39:36 kernel: br0: port 4(wds0.1) entering forwarding state
Feb 16 11:39:38 syslog: wlceventd_proc_event(507): eth1: Disassoc 1C:B7:2C:C5:16:E9, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 16 11:39:40 syslog: wlceventd_proc_event(490): eth2: Deauth_ind 1C:B7:2C:C5:16:EC, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 16 11:39:49 syslog: wlceventd_proc_event(526): eth2: Auth 1C:B7:2C:C5:16:EC, status: Successful (0), rssi:0
Feb 16 11:39:49 syslog: wlceventd_proc_event(555): eth2: Assoc 1C:B7:2C:C5:16:EC, status: Successful (0), rssi:0
Feb 16 11:39:49 kernel: br0: port 4(wds0.1) entering forwarding state
Feb 16 11:39:49 kernel: device wds0.1 left promiscuous mode
Feb 16 11:39:49 kernel: br0: port 4(wds0.1) entering disabled state
Feb 16 11:39:49 syslog: wlceventd_proc_event(526): eth1: Auth 1C:B7:2C:C5:16:E9, status: Successful (0), rssi:0
Feb 16 11:39:49 syslog: wlceventd_proc_event(555): eth1: Assoc 1C:B7:2C:C5:16:E9, status: Successful (0), rssi:0
Feb 16 11:39:49 kernel: device wds1.3 entered promiscuous mode
Feb 16 11:39:49 kernel: br0: topology change detected, propagating
Feb 16 11:39:49 kernel: br0: port 4(wds1.3) entering forwarding state
Feb 16 11:39:49 kernel: br0: port 4(wds1.3) entering forwarding state
Feb 16 11:39:49 kernel: device wds0.1 entered promiscuous mode
Feb 16 11:39:49 kernel: br0: topology change detected, propagating
Feb 16 11:39:49 kernel: br0: port 5(wds0.1) entering forwarding state
Feb 16 11:39:49 kernel: br0: port 5(wds0.1) entering forwarding state
Feb 16 11:39:51 syslog: wlceventd_proc_event(507): eth1: Disassoc 1C:B7:2C:C5:16:E9, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 16 11:39:52 dnsmasq-dhcp[1659]: DHCPDISCOVER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:39:52 dnsmasq-dhcp[1659]: DHCPOFFER(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:39:52 dnsmasq-dhcp[1659]: DHCPREQUEST(br0) 192.168.2.174 1c:b7:2c:c5:16:e8
Feb 16 11:39:52 dnsmasq-dhcp[1659]: DHCPACK(br0) 192.168.2.174 1c:b7:2c:c5:16:e8 RT-AC68U-16E8
Feb 16 11:39:52 dnsmasq-dhcp[1659]: DHCPDISCOVER(br0) ac:ae:19:a0:0b:d0
Feb 16 11:39:52 dnsmasq-dhcp[1659]: DHCPOFFER(br0) 192.168.2.23 ac:ae:19:a0:0b:d0
Feb 16 11:39:52 dnsmasq-dhcp[1659]: DHCPREQUEST(br0) 192.168.2.23 ac:ae:19:a0:0b:d0
Feb 16 11:39:52 dnsmasq-dhcp[1659]: DHCPACK(br0) 192.168.2.23 ac:ae:19:a0:0b:d0 Living-Room-Roku
Feb 16 11:39:55 kernel: br0: port 5(wds0.1) entering forwarding state
Feb 16 11:39:55 kernel: device wds0.1 left promiscuous mode
Feb 16 11:39:55 kernel: br0: port 5(wds0.1) entering disabled state
Feb 16 11:39:55 syslog: wlceventd_proc_event(526): eth1: Auth 1C:B7:2C:C5:16:E9, status: Successful (0), rssi:0
Feb 16 11:39:55 syslog: wlceventd_proc_event(555): eth1: Assoc 1C:B7:2C:C5:16:E9, status: Successful (0), rssi:0
Feb 16 11:39:55 kernel: device wds0.1 entered promiscuous mode
Feb 16 11:39:55 kernel: br0: topology change detected, propagating
Feb 16 11:39:55 kernel: br0: port 5(wds0.1) entering forwarding state
Feb 16 11:39:55 kernel: br0: port 5(wds0.1) entering forwarding state
Feb 16 11:39:57 rc_service: cfg_server 25322:notify_rc update_sta_binding
Feb 16 11:40:26 dnsmasq-dhcp[1659]: DHCPREQUEST(br0) 192.168.2.23 ac:ae:19:a0:0b:d0
Feb 16 11:40:26 dnsmasq-dhcp[1659]: DHCPACK(br0) 192.168.2.23 ac:ae:19:a0:0b:d0 Living-Room-Roku
Feb 16 11:43:03 dnsmasq-dhcp[1659]: DHCPREQUEST(br0) 192.168.2.234 00:51:ed:c2:a1:37
Feb 16 11:43:03 dnsmasq-dhcp[1659]: DHCPACK(br0) 192.168.2.234 00:51:ed:c2:a1:37 Living-Room-TV
Feb 16 11:43:03 kernel: 00:51:ED:C2:A1:37 not mesh client, can't update it's ip

Can anyone give any input as to what could be causing this?

 

[L&LD]

Welcome to the forums @fizix610.

I would not be troubleshooting this until you've flashed to RMerlin 386.1_2 release final first.

And if the issues continue, resetting the router to factory defaults afterward and minimally and manually configuring the router to secure it and connect to your ISP. Do not import a saved backup config file or 'blindly' use old settings/options or scripts that worked on previous firmware or router.

 

[danerine]

Yes, i am having the same issue with TS. My 86U master and 68U Aimesh node both are on 386.1_2 and factory reseted after upgrading the firmware. I am experiencing the frequent disconnection of the Aimesh node every day and having the exact same log messages as above so not sure what could be the reason causing this.

 

[fizix610]

Update: I bought a brand new RT-AC66U, updated the firmware to 386.1_2, reset to factory defaults, and connected it as an AiMesh node. It exhibits the exact same behavior. At this point, I can only conclude that this is a firmware issue and not a hardware or configuration issue.

 

[L&LD]

RT-AC66U?

 

[fizix610]

RT-AC66U?

Correct. It's the exact same firmware as the RT-AC68U

 

[ColinTaylor]

Correct. It's the exact same firmware as the RT-AC68U

RT-AC66U_B1 then. The RT-AC66U is a very old MIPS router that's completely different.

 

[fizix610]

RT-AC66U_B1 then. The RT-AC66U is a very old MIPS router that's completely different.

You're right. It's a B1

 

[dodko]

Hello, I have the same issue with an RT-AC66U_B1, operating as a node. My main router is a RT-AC68U, my wired nodes are 1xAC68U and 2xAC58U_v3. Wirelessly I have 2xAC66U_B1. One of the AC66Us is doing the same thing as mentioned in the first post, it would randomly disconnect from time to time, and reconnect after a minute to a different node, from the preferred one. I added the AC66Us two months ago, and before adding them I updated and reset all of the routers. All of them are running stock firmware.

 

[Mine Ong]

I am having the same issues. I have been experiencing disconnects, both in AiMesh node (wireless backhaul) or in media bridge mode, and both in AsusWRT and Merlin 386.2 (both AiMesh and router are always on the same firmware). When it happened today, I also noticed these entries in the syslog.txt, which is consistent with OP's log:

May  4 12:17:13 kernel: aa:bb:cc:xx:yy:zz not mesh client, can't update it's ip
May  4 12:17:16 kernel: nvram: consolidating space!
May  4 12:18:28 kernel: aa:bb:cc:xx:yy:zz not mesh client, can't update it's ip

the device with the mac address is a linux device with static IP. However, the IP it was assigned, while is in the range of the DHCP table of the AiMesh Router, is not IP-binded.

I have since moved its IP to outside of the DHCP range to see if it helps,

 

[fizix610]

I am having the same issues. I have been experiencing disconnects, both in AiMesh node (wireless backhaul) or in media bridge mode, and both in AsusWRT and Merlin 386.2 (both AiMesh and router are always on the same firmware). When it happened today, I also noticed these entries in the syslog.txt, which is consistent with OP's log:

May  4 12:17:13 kernel: aa:bb:cc:xx:yy:zz not mesh client, can't update it's ip
May  4 12:17:16 kernel: nvram: consolidating space!
May  4 12:18:28 kernel: aa:bb:cc:xx:yy:zz not mesh client, can't update it's ip

the device with the mac address is a linux device with static IP. However, the IP it was assigned, while is in the range of the DHCP table of the AiMesh Router, is not IP-binded.

I have since moved its IP to outside of the DHCP range to see if it helps,

Did moving it outside the DHCP range help?

 

[Gtothe]

I have the same issue... I ended up going all the way back to 384.13

I hope this gets resolved

 

[ItsMeDude]

Did moving it outside the DHCP range help?

I've had my RT-AC66U B1 set up with a static IP outside the DHCP range for a long time, and haven't had any issues with drops with it at all across several firmware revisions. It's possible that the drop could be the lease for the IP ending/renewing. You should give it a shot to see if it helps. Good luck!

 

[fizix610]

I've had my RT-AC66U B1 set up with a static IP outside the DHCP range for a long time, and haven't had any issues with drops with it at all across several firmware revisions. It's possible that the drop could be the lease for the IP ending/renewing. You should give it a shot to see if it helps. Good luck!

Are you using it as an AiMesh node? I didn't think it was possible to configure a static IP for a node.

 

[ItsMeDude]

Are you using it as an AiMesh node? I didn't think it was possible to configure a static IP for a node.

Yeah it's a mesh node with an AX88U as the main router. I just made a static IP with the node's MAC.

 

[fizix610]

Yeah it's a mesh node with an AX88U as the main router. I just made a static IP with the node's MAC.

Ahh, I see. So you made a DHCP reservation on your router as opposed to setting the IP statically on the node itself. Correct?

 

[ItsMeDude]

Ahh, I see. So you made a DHCP reservation on your router as opposed to setting the IP statically on the node itself. Correct?

Correct. I set it in the static list on the main router's LAN settings.

 

[bbunge]

Ahh, I see. So you made a DHCP reservation on your router as opposed to setting the IP statically on the node itself. Correct?

Most folks do not know the difference between static IP, reserved IP or manually assigned IP.
I have AC66U_B1 router with two AC68U nodes (manually assigned IP address) that have been up on Asus Beta firmware since Feb 3rd.

 

[bbunge]

Correct. I set it in the static list on the main router's LAN settings.

No, that is manually assigned!
Static addresses are assigned at the client.

 

[fizix610]

Quick update: I attached the AiMesh Node via ethernet (actually ethernet over coax) backhaul and have had no issues. The issue must be relegated to wireless backhaul only.