AC68U fell off the AiMesh node from AC86U router..2nd time

[jpthsd]

Hello,
Anyone seen this? AC86U router, AC68U Aimesh Node, both are 384.17 (upgraded to 384.17, restore default manufacturer, even hard reset as well)..

1st time happened on Tuesday, AC68U just fell out the AiMesh node and on AC86U reported Offline but it was still working (wifi client still connected to the AC68U AiMesh Node). So I had to remove it and rejoin the AC68 to AiMesh again.

Today, it just suddenly fell off again as shown in the screenshot. Anyone experience and solve this?

This is what I found in the log, it looks like the AC68U tried to obtain the DHCP again,,,maybe I need to reserve it as AiMesh node?

Appreciate any input and help!

Jun 5 13:19:59 dnsmasq-dhcp[943]: DHCPDISCOVER(br0) 192.168.200.55 ac:9e:17:7f:10:50
Jun 5 13:19:59 dnsmasq-dhcp[943]: DHCPOFFER(br0) 192.168.200.55 ac:9e:17:7f:10:50
Jun 5 13:19:59 dnsmasq-dhcp[943]: DHCPDISCOVER(br0) 192.168.200.55 ac:9e:17:7f:10:50
Jun 5 13:19:59 dnsmasq-dhcp[943]: DHCPOFFER(br0) 192.168.200.55 ac:9e:17:7f:10:50
Jun 5 13:20:00 dnsmasq-dhcp[943]: DHCPREQUEST(br0) 192.168.200.55 ac:9e:17:7f:10:50
Jun 5 13:20:00 dnsmasq-dhcp[943]: DHCPACK(br0) 192.168.200.55 ac:9e:17:7f:10:50 RT-AC68U-1050

 

[jpthsd]

by the time I was writing this thread, the AiMesh node reported Online again...it looks like the cycle on & offline while DHCP renewal process...I just created reserved for the RT-AC68U's MAC..hope it won't happen again or maybe this is the norm??

Anyone?

 

[OzarkEdge]

by the time I was writing this thread, the AiMesh node reported Online again...it looks like the cycle on & offline while DHCP renewal process...I just created reserved for the RT-AC68U's MAC..hope it won't happen again or maybe this is the norm??

Anyone?

Wireless backhaul? How far? How noisy around you? How strong are the 2.4/5.0 backhaul RSSI/Tx/Rx values for the node MACs in the Wireless Log? Is the 86U using different SSIDs?

OE

 

[jpthsd]

Wireless backhaul? How far? How noisy around you? How strong are the 2.4/5.0 backhaul RSSI/Tx/Rx values for the node MACs in the Wireless Log? Is the 86U using different SSIDs?

OE

About 30 feet away, 2 walls, and yes Wireless backhaul. Aimesh's been reporting full strenth/excellent strength.

Nope, single Wifi SSID.

The MAC below is the 5G MAC of the AC68U

AC:9E:17:7F:10:54 Yes Yes -61dBm ac No Yes Yes No 3 866.7M 866.7M 03:16:03

 

[jpthsd]

Interesting while AiMesh Node AC68U reported Offline in AC86U admin portal, Internet still worked for those wifi client connected to that AiMesh node..it was like 5-10 mins the AiMesh node AC68U reported Online again the exact the time it was reported in the logs..

 

[OzarkEdge]

I would want to try different SSIDs (and fixed and various channels). Then stock firmware.

OE

 

[bbunge]

Flash the AC86U to Asus 384.81918. Use Dual Band SmartConnect with fixed 2.4 and 5 GHZ channels. Flash the AC68U to Asus firmware, too. Set up AiMesh and it should have no issues.

 

[MarkyPancake]

I'm pretty sure the 68U doesn't support Smart Connect, so not sure your usual setup will work here.

 

[jpthsd]

I'm pretty sure the 68U doesn't support Smart Connect, so not sure your usual setup will work here.

Actually, when AC68U flashed to latest Asuswrt , it does have Smart Connect on/off menu. But it doesn't mean it will support it or not lol,,,you're right, it is not on the list!

https://www.asus.com/us/support/FAQ/1012132/

 

[jpthsd]

Flash the AC86U to Asus 384.81918. Use Dual Band SmartConnect with fixed 2.4 and 5 GHZ channels. Flash the AC68U to Asus firmware, too. Set up AiMesh and it should have no issues.

It's been using 5Ghz as backhaul but I do not use band steering ,,,by having each 2.4 & 5Ghz its own SSID, I am easily controlling. ...plus AC68U doesn't support Smart Connect!

Maybe I get another AC86U and then follow you suggestion later

So far, I created DHCP reservation for AC68U AiMesh Node,,,seems to work well!

 

[jpthsd]

This should be resolved. It's been almost 3 days, no re-occurrence!

I think the DHCP might have caused the on/off of the AiMesh Node plus the signal integrity, strength checkup as well!

The logs be low showed that times to times, the AiMesh node being checked if the signal strength strong enough to be wireless backhaul plus DHCP ack ..etc

Thus, DHCP reservation for the AiMesh node seemed to help as well!!

Thank you everyone! Hope it helps if someone has the same issue like mine

DHCP ack
Jun 7 13:20:00 dnsmasq-dhcp[29216]: DHCPREQUEST(br0) 192.168.200.55 ac:9e:17:7f:10:50
Jun 7 13:20:00 dnsmasq-dhcp[29216]: DHCPACK(br0) 192.168.200.55 ac:9e:17:7f:10:50 RT-AC68U

Signal integrity/strength/roam check
Jun 7 23:15:04 roamast: determine candidate node [AC:9E:17:7F:10:50](rssi: -52dbm) for client [04B:56:26:6E8](rssi: -71dbm) to roam

 

[ChoppedBroccoli]

This should be resolved. It's been almost 3 days, no re-occurrence!

I think the DHCP might have caused the on/off of the AiMesh Node plus the signal integrity, strength checkup as well!

The logs be low showed that times to times, the AiMesh node being checked if the signal strength strong enough to be wireless backhaul plus DHCP ack ..etc

Thus, DHCP reservation for the AiMesh node seemed to help as well!!

Thank you everyone! Hope it helps if someone has the same issue like mine

DHCP ack
Jun 7 13:20:00 dnsmasq-dhcp[29216]: DHCPREQUEST(br0) 192.168.200.55 ac:9e:17:7f:10:50
Jun 7 13:20:00 dnsmasq-dhcp[29216]: DHCPACK(br0) 192.168.200.55 ac:9e:17:7f:10:50 RT-AC68U

Signal integrity/strength/roam check
Jun 7 23:15:04 roamast: determine candidate node [AC:9E:17:7F:10:50](rssi: -52dbm) for client [04B:56:26:6E8](rssi: -71dbm) to roam

Question - did you set up DHCP reservation for the RT-68U on its 5GHz MAC, its 2.4Ghz MAC, or the MAC address that shows up under Network Map->AiMesh node->Click on node->Click 'More config'? I'm guessing you chose the MAC address and IP address listed under the AiMesh node config?
For now I'm going to choose MAC+IP under AiMesh node config and see how that works...




My setup is Main node 68U on merlin 384.18 and one 68U node on ASUS 33.0.0.4.385_20490-g57b06ea with wireless backhaul.

Airtime fairness off, fixed channels (8oMHZ, Ch 40 on 5GHZ / 20MHZ, Ch 8 on 2.4GHZ), airtime fairness and universal disabled, roaming assistant enabled and at -62db on both.

I have fantastic speed and coverage, but the AiMesh node just kicks off intermittently while the main node is completely fine. It doesn't matter if I place the node in 4-5 bar range (5G -55b, 2G -40db) or 2-3 bar range (5G -65db, 2G -50db) same result.

 

[jpthsd]

Question - did you set up DHCP reservation for the RT-68U on its 5GHz MAC, its 2.4Ghz MAC, or the MAC address that shows up under Network Map->AiMesh node->Click on node->Click 'More config'? I'm guessing you chose the MAC address and IP address listed under the AiMesh node config?
For now I'm going to choose MAC+IP under AiMesh node config and see how that works...




My setup is Main node 68U on merlin 384.18 and one 68U node on ASUS 33.0.0.4.385_20490-g57b06ea with wireless backhaul.

Airtime fairness off, fixed channels (8oMHZ, Ch 40 on 5GHZ / 20MHZ, Ch 8 on 2.4GHZ), airtime fairness and universal disabled, roaming assistant enabled and at -62db on both.

I have fantastic speed and coverage, but the AiMesh node just kicks off intermittently while the main node is completely fine. It doesn't matter if I place the node in 4-5 bar range (5G -55b, 2G -40db) or 2-3 bar range (5G -65db, 2G -50db) same result.

I reserved base on the MAC (ping the AiMesh node in command prompt then do arp -a , it should return MAC for that AiMesh node) and because that was what I saw in the log when the AiMesh node renewed its IP via DHCP.

It's been a while since mine were upgraded to 384.18 and the AC68U still attached to the AiMesh node without falling off , knock on woods

For home use, it is not big deal , if it falls off the AiMesh, just do power reset as it doesn't fall off too often (I remember it was happened twice since I upgraded to 384.17 in a month)

 

[ChoppedBroccoli]

I reserved base on the MAC (ping the AiMesh node in command prompt then do arp -a , it should return MAC for that AiMesh node) and because that was what I saw in the log when the AiMesh node renewed its IP via DHCP.

It's been a while since mine were upgraded to 384.18 and the AC68U still attached to the AiMesh node without falling off , knock on woods

For home use, it is not big deal , if it falls off the AiMesh, just do power reset as it doesn't fall off too often (I remember it was happened twice since I upgraded to 384.17 in a month)

I wish I had your luck! I ended up trying different combinations like trying the main MAC address of the node and also trying the wireless interface MAC addresses as well in the DHCP reservation table.

Also tried this roaming block list setting discussed here:
https://www.reddit.com/r/HomeNetwor...possible_aimesh_dropout_fix_add_nodes_to_new/

Nothing worked unfortunately. Didn't matter whether the node was 20ft away or 50ft away, at some point the node would go offline multiple times a day, but unlike your previous post, my clients connected to the node would lose internet and bounce to the weak signal of the main router. Unusable for work video calls.

I wonder if its just a bug that affects RT-AC68U only setups (my setup is 2x RT-AC68U both running merlin 384.18)?

For now just using some extra ethernet cable to connect them until I find time to route it under the house. If anyone has other ideas let me know

 

[jpthsd]

Uhmmm ,,,that's the difference ..mine Aimesh is AC86U main and AC68U AiMesh node.

I found that it is not right time to spend $$ for Wifi 6 until WiFi 6E coming out...but I am surprise that the setup works very well for 3 x 4K TV, 5 computers, 4 iPad, 6 iphone with 1600 sqt house coverage!

Try to get AC86U, it works very well (if you decide to get it, the first one or two day use, if the AC86U restart itself while changing some simple configuration, return it immediately and get another one from usually Amazon easy ship/return)

 

[ChoppedBroccoli]

Uhmmm ,,,that's the difference ..mine Aimesh is AC86U main and AC68U AiMesh node.

I found that it is not right time to spend $$ for Wifi 6 until WiFi 6E coming out...but I am surprise that the setup works very well for 3 x 4K TV, 5 computers, 4 iPad, 6 iphone with 1600 sqt house coverage!

Try to get AC86U, it works very well (if you decide to get it, the first one or two day use, if the AC86U restart itself while changing some simple configuration, return it immediately and get another one from usually Amazon easy ship/return)

Good to know. I'm yet to find anyone who has 2 RT-68U on wireless backhaul working reliably

Will keep an eye out for AC86U.

 

[ChoppedBroccoli]

Wanted to come back here with an update to save someone else a ton of frustration and time:


Even after a wired ethernet backhaul I noticed that wireless devices attached to the main router and the mesh node would randomly disconnect with some sort of deauth, auth, assoc pattern logged on the wireless interface. I could go as much as a day or two before seeing something like this, but it would get more frequent with more uptime:

Aug 20 15:57:59 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind MAC, status: 0, reason: Class 3 frame received from nonassociated station (7)
Aug 20 15:57:59 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth MAC, status: Successful (0)
Aug 20 15:57:59 syslog: WLCEVENTD wlceventd_proc_event(529): eth1: Assoc MAC, status: Successful (0)

I read somewhere that Merlin build 384.14 in late 2019 brought in some ASUS changes with this type of bug. It was really hard to figure out if this was the case, because there are also many people complaining about logging bugs related DHCP and wireless clients around this time. Nevertheless, I downgraded to build 384.13 and now nearly 72 hours later not a single problem for any client on my network. Will report back if this changes, but it seems like ASUS introduced either a wireless bug or an AiMesh bug mid 2019. It is possible I would have run into other AiMesh bugs even on Merlin build 384.13 that I previously solved with a wired ethernet backhaul so 384.13 is not a panacea in itself.

If you ever needed do a cost analysis of a bug...lol ! I spent dozens of hours trying to fix this (maybe even a week's worth of hours) spread out over the course of 4 months ‍‍. How many human hours in total have been lost to this bug among ASUS customers?!?

In the end I'm happy I got it to work, because fundamentally reusing old routers for a mesh network is more appealing than buying new gear for no reason (rather wait for cheap WiFi 6e in a few years). On the flipside, being stuck on 384.13 due to this bug and missing out on security fixes is not good.

I hope someone setting RT-AC68U routers up with AiMesh sees this post before they go down many rabbit holes!

 

[ChoppedBroccoli]

Hello,
Anyone seen this? AC86U router, AC68U Aimesh Node, both are 384.17 (upgraded to 384.17, restore default manufacturer, even hard reset as well)..

1st time happened on Tuesday, AC68U just fell out the AiMesh node and on AC86U reported Offline but it was still working (wifi client still connected to the AC68U AiMesh Node). So I had to remove it and rejoin the AC68 to AiMesh again.

Today, it just suddenly fell off again as shown in the screenshot. Anyone experience and solve this?

This is what I found in the log, it looks like the AC68U tried to obtain the DHCP again,,,maybe I need to reserve it as AiMesh node?

Appreciate any input and help!

Jun 5 13:19:59 dnsmasq-dhcp[943]: DHCPDISCOVER(br0) 192.168.200.55 ac:9e:17:7f:10:50
Jun 5 13:19:59 dnsmasq-dhcp[943]: DHCPOFFER(br0) 192.168.200.55 ac:9e:17:7f:10:50
Jun 5 13:19:59 dnsmasq-dhcp[943]: DHCPDISCOVER(br0) 192.168.200.55 ac:9e:17:7f:10:50
Jun 5 13:19:59 dnsmasq-dhcp[943]: DHCPOFFER(br0) 192.168.200.55 ac:9e:17:7f:10:50
Jun 5 13:20:00 dnsmasq-dhcp[943]: DHCPREQUEST(br0) 192.168.200.55 ac:9e:17:7f:10:50
Jun 5 13:20:00 dnsmasq-dhcp[943]: DHCPACK(br0) 192.168.200.55 ac:9e:17:7f:10:50 RT-AC68U-1050

Did the DHCP AiMesh node reservation trick continue to work?

For others: I suggest putting your logs at the most verbose level (info level , log all messages). I think the DHCP activity could just be the symptom of an unlogged wireless disconnect prior to this. I would see these DHCP messages like this usually around deauth, auth, assoc wireless disconnect on Merlin builds post 384.13

 

[jpthsd]

Did the DHCP AiMesh node reservation trick continue to work?

For others: I suggest putting your logs at the most verbose level (info level , log all messages). I think the DHCP activity could just be the symptom of an unlogged wireless disconnect prior to this. I would see these DHCP messages like this usually around deauth, auth, assoc wireless disconnect on Merlin builds post 384.13

Yes,,,it's been working almost a month without any issue 384_18 (nah ,,384_19 not now...maybe later,,,I am so stable on 384_18_)