IoT Devices falling off nodes (only) always requires reboot to fix

[jksmurf]

Hi,

I’m struggling with what should be a perfectly robust system, chosen for compatibility after many discussions on this forum surrounding GNP and VLANs. I’m currently at my remote site but have been struggling with this for almost a week, only have a week left and won’t be back for another year. Three all (and only) fully GNP capable Routers, all VLAN capable (not important for this discussion though).

• GT-AX6000 Main on Merlin FW 3006.102.6 b2
• 2 x RT-AX86U Pro Nodes, also on Merlin FW 3006.102.6 b2 (will try stock soon)
• Wired Ethernet BH, set to Auto.
• Mostly stock settings. Smart Connect, just because I prefer it. Addons as shown in sig.

Issue is with Shelly IoT devices on nodes. Note that I am using static assignments on the devices and have only one of the two Shelly Wi-Fi options set up on the web interface of the Shelly’s.

They connect and then if I reboot the main (separate thread on whether this also reboots nodes), then many of the devices on the nodes (only) just fail to reconnect.

However if I then subsequently reboot the nodes, the devices come back fine.

A second issue is that they occasionally fall off the nodes and stay off. I am not hiding the SSIDs and they should reconnect. A reboot of the node also fixes this.

On Main the devices always connect and stay up just fine.

I really don’t want to schedule reboots on the nodes (and should not have to).

Will try stock on nodes soon but would really very much appreciate some suggestions to try or troubleshooting steps to post here, just feel the clock ticking by on what i thought would be a simple upgrade from a mixed 3006/3004 codebase system to 3006/3006 with the same mature Wi-Fi 6 gen routers.

Thanks!

 

[sfx2000]

There really are no magic settings - wifi either works or it doesn't.

No device is perfect - either replace the IoT devices or replace the router with a different brand.

 

[John Fitzgerald]

Merlin FW 3006.102.6 RELEASE is now available.

Release - Asuswrt-Merlin 3006.102.6 is now available

Asuswrt-Merlin 3006.102.6 is now available. This release focuses on new GPL merge, a complete redesign of the Traffic Monitor pages, and the addition of two new models: RT-BE58_Go - https://www.asus.com/networking-iot-servers/wifi-7/all-series/rt-be58-go/ GT-BE19000AI -...

www.snbforums.com

 

[jksmurf]

Merlin FW 3006.102.6 RELEASE is now available.

Release - Asuswrt-Merlin 3006.102.6 is now available

Asuswrt-Merlin 3006.102.6 is now available. This release focuses on new GPL merge, a complete redesign of the Traffic Monitor pages, and the addition of two new models: RT-BE58_Go - https://www.asus.com/networking-iot-servers/wifi-7/all-series/rt-be58-go/ GT-BE19000AI -...

www.snbforums.com

Thank you, I did update it but the issues remain, which was not unexpected.

 

[John Fitzgerald]

Thank you, I did update it but the issues remain, which was not unexpected.

What happens when you run stock on the nodes.

 

[Tech9]

Mostly stock settings. Smart Connect, just because I prefer it.

Means you ignore ASUS IoT compatibility settings and the recommendations made by multiple SNB Forum members. You have a week time to change your preferences and try something else, I guess.

 

[jksmurf]

Means you ignore ASUS IoT compatibility settings and the recommendations made by multiple SNB Forum members. You have a week time to change your preferences and try something else, I guess.

OK, I'm desperate enough; what were those recommended settings again?

 

[doczenith1]

OK, I'm desperate enough; what were those recommended settings again?

I'd start with this for 2.4 GHz.

 

[jksmurf]

OK, so it seems the issue is caused by a loop, due to a newly added Switch.

Network Topology is:

ONT->Primary Router->5-Port Unmanaged Switch; Uplink Port 5
THEN
a. Unmanaged Switch Port 2-> Node1 (aside: VLAN Ethernet Port 1 is set as Access for IoT, VLAN63)
b. Unmanaged Switch Port 3-> Node2 (aside: VLAN Ethernet Port 1 is set as Access for IoT, VLAN63)
c. Umanaged Switch Port 4-> to 5 Port TP Link SG105E Managed Switch with configs as attached (FINAL; I did have ORIG but same issue).
One cable to a wall jack on Port 1 but not used.

The Managed Switch has one uplink and 4 links to (all) VLAN ID 63 devices (HA Server, two Xiaomi gateways, one ESP32). The purpose of this switch is to tag all attached (via Ethernet cable...) devices so they sit on VLAN ID 63.

Now, in testing, when I take the TP Link OUT of play i.e. just Main plus two nodes,, there are no errors. Adding back the switch with JUST the uplink, adds back the errors. I am prretty raw at Switch configuration, could soneone cast their eye over what I have done here please? @visortgw or @Seth Harman if you recall the long thread on this topic?

ASUSWRT-Merlin RT-AX86U_PRO 3006.102.6_0 Tue Nov 25 15:54:09 UTC 2025
AubreyHus@RT-AX86_Pro_ANX:/tmp/home/root# dmesg | tail -30
CFG80211-ERROR) wl_cfg80211_set_rekey_data :
seting gtk_key_info failed code=-23
CFG80211-ERROR) wl_cfg80211_disconnect :
Reason 3
CFG80211-ERROR) wl_notify_connect_status :
link down if eth7 may call cfg80211_disconnected. event : 11, reason=8 from 10:7c:61:2b:eb:ec
dev eth7.62 is sdn_ignore
dev eth7.63 is sdn_ignore
br0: port 1(eth0) entered blocking state
br0: port 1(eth0) entered disabled state
br0: port 1(eth0) entered blocking state
br0: port 1(eth0) entered forwarding state
br0: received packet on eth0 with own address as source address (addr:c8:7f:54:bf:ba:48, vlan:0)
br0: received packet on eth0 with own address as source address (addr:c8:7f:54:bf:ba:48, vlan:0)
br0: received packet on eth0 with own address as source address (addr:c8:7f:54:bf:ba:48, vlan:0)
br0: received packet on eth0 with own address as source address (addr:c8:7f:54:bf:ba:48, vlan:0)
br0: received packet on eth0 with own address as source address (addr:c8:7f:54:bf:ba:48, vlan:0)
CFG80211-ERROR) wl_dfs_cac_notify_status :
In wl_dfs_cac_notify_status chanspec 0xe09b DFS state 0
CFG80211-ERROR) wl_dfs_cac_notify_status :
In wl_dfs_cac_notify_status chanspec 0xe09b DFS state 0
br0: port 1(eth0) entered disabled state
br0: port 1(eth0) entered blocking state
br0: port 1(eth0) entered disabled state
br0: port 1(eth0) entered blocking state
br0: port 1(eth0) entered forwarding state
br0: received packet on eth0 with own address as source address (addr:c8:7f:54:bf:ba:48, vlan:0)
br0: received packet on eth0 with own address as source address (addr:c8:7f:54:bf:ba:48, vlan:0)
br0: received packet on eth0 with own address as source address (addr:c8:7f:54:bf:ba:48, vlan:0)
br0: received packet on eth0 with own address as source address (addr:c8:7f:54:bf:ba:48, vlan:0)
AubreyHus@RT-AX86_Pro_ANX:/tmp/home/root#
AubreyHus@RT-AX86_Pro_ANX:/tmp/home/root#

This is the test from when I took the managed Switch out of play:

Using username "AubreyHus".
[email protected]'s password:
ASUSWRT-Merlin RT-AX86U_PRO 3006.102.6_0 Tue Nov 25 15:54:09 UTC 2025
AubreyHus@RT-AX86_Pro_MB:/tmp/home/root#
AubreyHus@RT-AX86_Pro_MB:/tmp/home/root#
AubreyHus@RT-AX86_Pro_MB:/tmp/home/root# dmesg | tail -30
0000: eb ba bd c6 4a 4b 29 a2 81 84 00 61 36 0d f9 02
replay_ctr:
0000: 00 00 00 00 00 00 00 02
CFG80211-ERROR) wl_cfg80211_set_rekey_data :
seting gtk_key_info failed code=-23
CFG80211-ERROR) wl_cfg80211_disconnect :
Reason 3
CFG80211-ERROR) wl_notify_connect_status :
link down if eth7 may call cfg80211_disconnected. event : 11, reason=8 from 10:7 c:61:2b:eb:ec
dev eth7.62 is sdn_ignore
dev eth7.63 is sdn_ignore
br0: port 1(eth0) entered blocking state
br0: port 1(eth0) entered disabled state
br0: port 1(eth0) entered blocking state
br0: port 1(eth0) entered forwarding state
CFG80211-ERROR) wl_dfs_cac_notify_status :
In wl_dfs_cac_notify_status chanspec 0xe09b DFS state 0
CFG80211-ERROR) wl_dfs_cac_notify_status :
In wl_dfs_cac_notify_status chanspec 0xe09b DFS state 0
br0: port 1(eth0) entered disabled state
br0: port 1(eth0) entered blocking state
br0: port 1(eth0) entered disabled state
br0: port 1(eth0) entered blocking state
br0: port 1(eth0) entered forwarding state
CFG80211-ERROR) wl_dfs_cac_notify_status :
In wl_dfs_cac_notify_status chanspec 0xe832 DFS state 1
CFG80211-ERROR) wl_dfs_cac_notify_status :
In wl_dfs_cac_notify_status chanspec 0xe09b DFS state 0
CFG80211-ERROR) wl_dfs_cac_notify_status :
In wl_dfs_cac_notify_status chanspec 0xe09b DFS state 0
AubreyHus@RT-AX86_Pro_MB:/tmp/home/root#

Using username "AubreyHus".
[email protected]'s password:
ASUSWRT-Merlin RT-AX86U_PRO 3006.102.6_0 Tue Nov 25 15:54:09 UTC 2025
AubreyHus@RT-AX86_Pro_ANX:/tmp/home/root# dmesg | tail -30
Tuxera NTFS driver 3021.4.23.14 [Flags: R/W MODULE].
Built against headers 4.19.183 #1 SMP PREEMPT Wed Oct 11 14:58:32 CST 2023 aarch 64
Running on kernel 4.19.183 #1 SMP PREEMPT Tue Nov 25 10:54:40 EST 2025 aarch64
Tuxera HFS+ driver 3020.11.30d
Built against headers 4.19.183 #1 SMP PREEMPT Wed Oct 11 14:58:32 CST 2023 aarch 64
Running on kernel 4.19.183 #1 SMP PREEMPT Tue Nov 25 10:54:40 EST 2025 aarch64
init (1): drop_caches: 1
CFG80211-ERROR) wl_cfg80211_disconnect :
Reason 3
CFG80211-ERROR) wl_notify_connect_status :
link down if eth6 may call cfg80211_disconnected. event : 11, reason=8 from 10:7 c:61:2b:eb:e8
dev eth6.62 is sdn_ignore
dev eth6.63 is sdn_ignore
CFG80211-ERROR) wl_notify_connect_status :
link down if eth7 may call cfg80211_disconnected. event : 11, reason=8 from 10:7 c:61:2b:eb:ec
dev eth7.62 is sdn_ignore
dev eth7.63 is sdn_ignore
br0: port 1(eth0) entered blocking state
br0: port 1(eth0) entered disabled state
br0: port 1(eth0) entered blocking state
br0: port 1(eth0) entered forwarding state
CFG80211-ERROR) wl_dfs_cac_notify_status :
In wl_dfs_cac_notify_status chanspec 0xe09b DFS state 0
CFG80211-ERROR) wl_dfs_cac_notify_status :
In wl_dfs_cac_notify_status chanspec 0xe09b DFS state 0
br0: port 1(eth0) entered disabled state
br0: port 1(eth0) entered blocking state
br0: port 1(eth0) entered disabled state
br0: port 1(eth0) entered blocking state
br0: port 1(eth0) entered forwarding state
AubreyHus@RT-AX86_Pro_ANX:/tmp/home/root#

 

[jksmurf]

OK, I think I (Claude and I) have worked it out (per attached), if anyone can see what I did wrong and if this helps someone else, then all the better.

us@RT-AX86_Pro_ANX:/tmp/home/root# dmesg | tail -30
link down if eth7 may call cfg80211_disconnected. event : 11, reason=8 from 10:7c:61:2b:eb:ec
br0: port 1(eth0) entered blocking state
br0: port 1(eth0) entered disabled state
br0: port 1(eth0) entered blocking state
br0: port 1(eth0) entered forwarding state
CFG80211-ERROR) wl_cfg80211_connect :
Connecting with10:7c:61:2b:eb:ec ssid "47AubreyRd", len (10) channel=149

CFG80211-ERROR) wl_cfg80211_scan_abort :
scan abort failed
dev eth7.62 is sdn_ignore
dev eth7.63 is sdn_ignore
kck:
0000: 69 0b 10 2e 15 fe 50 73 7c 17 71 c8 13 f9 c9 ca
kek:
0000: 3c 73 4c bc 25 09 f6 2d 30 a8 0c c0 10 f6 e9 b0
replay_ctr:
0000: 00 00 00 00 00 00 00 02
CFG80211-ERROR) wl_cfg80211_set_rekey_data :
seting gtk_key_info failed code=-23
CFG80211-ERROR) wl_cfg80211_disconnect :
Reason 3
CFG80211-ERROR) wl_notify_connect_status :
link down if eth7 may call cfg80211_disconnected. event : 11, reason=8 from 10:7c:61:2b:eb:ec
dev eth7.62 is sdn_ignore
dev eth7.63 is sdn_ignore
CFG80211-ERROR) wl_dfs_cac_notify_status :
In wl_dfs_cac_notify_status chanspec 0xe09b DFS state 0
CFG80211-ERROR) wl_dfs_cac_notify_status :
In wl_dfs_cac_notify_status chanspec 0xe09b DFS state 0
AubreyHus@RT-AX86_Pro_ANX:/tmp/home/root#

 

[jksmurf]

What happens when you run stock on the nodes.

Not ignoring the suggestion here John, just seemed to be having a few issues all around the same time. I seem to have got rid of some kernel panic issues by swapping an 8 port unmanaged PoE switch on which the power brick 53.6v 1.22A) was humming a fair bit, to a 5 port simple, 5V one, panic logs below.

After that I seem (fingers crossed) to have fixed Shelly’s dropping off the Wi-Fi and staying off, by fixing the managed switch as described above. The system seems stable and fast. Might have to investigate whether some ESP32 BT Proxy devices close to the router are causing interference but that seems relatively minor.

I might look into stock later but I think the biggest issue was my poorly (by me) configured managed switch.

Nov 27 08:29:54 kernel: Kernel panic - not syncing: Fatal exception in interrupt
Nov 27 08:29:54 kernel: CPU: 1 PID: 0 Comm: swapper/1 Tainted: P O 4.19.183 #2

Nov 27 08:30:15 wlceventd: wlceventd_proc_event(491): eth7: Deauth_ind xx:xx:xx:xx:xx:xx, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0

 

[John Fitzgerald]

Not ignoring the suggestion here John, just seemed to be having a few issues all around the same time. I seem to have got rid of some kernel panic issues by swapping an 8 port unmanaged PoE switch on which the power brick 53.6v 1.22A) was humming a fair bit, to a 5 port simple, 5V one, panic logs below.

After that I seem (fingers crossed) to have fixed Shelly’s dropping off the Wi-Fi and staying off, by fixing the managed switch as described above. The system seems stable and fast. Might have to investigate whether some ESP32 BT Proxy devices close to the router are causing interference but that seems relatively minor.

I might look into stock later but I think the biggest issue was my poorly (by me) configured managed switch.

I get your reasoning of having the same GPL on main and nodes.
Each environment is unique.
VLAN control at nodes is your unique setup.
Because AiMesh is closed source and proprietary some claim that nodes should just remain on stock, the head unit controls the function. No RMerlin involved in that aspect.
No right or wrong, just environment, your setup and trial to determine performance.

Glad you are getting it sorted, good luck!
Happy Holiday!

 

[Seth Harman]

Spoiler: Screenshot of switch configuration

View attachment 69182

What you've done differently than I have (and what those instructions I referenced a long time ago explain) is your entire range of ports is supposed to be configured as part of the VLAN 1 configuration. Here's my setup with Port 1 as the uplink to the AiMesh node:

For VLAN ID 1 try setting 1-5 as your member ports and 1-5 as your untagged ports.

 

[jksmurf]

What you've done differently than I have (and what those instructions I referenced a long time ago explain) is your entire range of ports is supposed to be configured as part of the VLAN 1 configuration. Here's my setup with Port 1 as the uplink to the AiMesh node:

For VLAN ID 1 try setting 1-5 as your member ports and 1-5 as your untagged ports.

Thank you, I’ll see how the current setup goes, bit nervous about changing it again after I got it configured to get rid of the loop that was in place from my original config (see above), which (I’m not 100% sure) have leveraged the link to the forum setup you posted a while back.

ATM I don’t have any loop errors as far as I can tell and the Shelly’s are behaving too. I can’t access the switch but that’s a minor inconvenience atm. Just… super tired … very time consuming, testing trialing etc. with little sleep.

 

[Seth Harman]

Thank you, I’ll see how the current setup goes, bit nervous about changing it again after I git it configured to get rid of the loop that was in place from my original config (see above), which (I’m not 100% sure) have leveraged the link to the forum setup you posted a while back.

ATM I don’t have any loop errors as far as I can tell and the Shelly’s are behaving too. I can’t access the switch but that’s a minor inconvenience atm. Just… super tired … very time consuming, testing trialing etc. with little sleep.

Whatever ends up working for you is obviously the way to go, but I specifically went by that guide that's been referenced a few times and my setup is working flawlessly, i.e. the wired devices hooked up to ports 2-5 are part of the RSIOT VLAN ID 53 and function exactly as intended. The fact that you can't log into the switch is a problem, I can log into mine without issue (it's got an IP address assigned from the default (VLAN ID 1) 192.168.1.x range).

 

[jksmurf]

Whatever ends up working for you is obviously the way to go, but I specifically went by that guide that's been referenced a few times and my setup is working flawlessly, i.e. the wired devices hooked up to ports 2-5 are part of the RSIOT VLAN ID 53 and function exactly as intended. The fact that you can't log into the switch is a problem, I can log into mine without issue (it's got an IP address assigned from the default (VLAN ID 1) 192.168.1.x range).

I ended up reconfiguring the Switch so I could access it, albeit only a static IP on the switch worked, to use the IP address I was trying to manually assign it. It was always given a DHCP address instead, just didn’t accept my one, even after triple checking it was correct. Seemed like a timing issue, it just a guess. Works perfectly with a static address.

 

[Seth Harman]

I ended up reconfiguring the Swirch so I could access it, albeit only a static IP on the switch worked, to use the IP address I was trying to manually assign it. It was always given a DHCP address instead, just didn’t accept my one, even after triple checking it was correct. Seemed like a timing issue, it just a guess. Works perfectly with a static address.

Good to hear!

 

[jksmurf]

Means you ignore ASUS IoT compatibility settings and the recommendations made by multiple SNB Forum members. You have a week time to change your preferences and try something else, I guess.

OK, I'm desperate enough; what were those recommended settings again?

I'd start with this for 2.4 GHz.

OK, I am back from my trip to my second network site and thought I would record what I did to achieve what I wanted and why I did it; maybe it will help someone (and confuse the heck out of the rest of you).

FIRST

First, as much as it pains me to admit it (TIC), I have come to the conclusion that @Tech9 is probably correct that AiMesh with stock settings simply does not work for more complex scenarios e.g. for weak IoT devices on 2.4Ghz and strong iOS devices on 5Ghz and a mix of Main and Node Router Hardware with different FW Codebase and TX Powers. This is not to say you cannot run Smart Connect (I still do) but you do need some other tweaks, for the reasons I outline below.

Only @bbunge seems to run everything at stock settings (even if not with stock FW) and apparently make it work and good luck to him for that.

BACKGROUND

I had previously tried an RT-AX86U Pro with two ZenWifi XD6's and one RT-AX58U as nodes (all wired BH) and maybe some of the changes I elaborate on below would have helped with the underlying issue of IoT devices dropping off the nodes (and needing a reboot to get them back on, which did not always work), but I had reason to change the previous system which is now a GT-AX6000 Main with two RT-AX86U Pro and one RT-AX58U as AiMesh nodes (all wired BH).

REVISED HARDWARE

The reason for the change was partly to have some Ethernet devices attached to Nodes Ethernet Ports but which I wanted on the IoT network subnet (63) and partly for a robust centrally managed system. Only VLAN capable devices are able to be centrally configured from the main router to propagate subnets from the Ethernet Ports of Nodes. A discussion on the current lists of ASUS GNP and (separately) VLAN-capable nodes is here. In addition, one of the oddly named "Easy-Smart Managed" switch line from TPLink, the TL-SG105E, now sits behind the RT-AX58U and this Switch allows me to assign IoT subnet IP addresses to attached Ethernet devices, so all node locations have that capability, one way or another.

The Main Network is subnet (47), the Guest Network is subnet (62) and I use the truly excellent YazDHCP for DHCP assignments, huge thanks to @Martinski for expanding YazDHCP to Guest Networks, it changes everything.

The original RT-AX86U Pro (3006 Merlin) as Main and ZenWifi XD6 (3004 stock codebase) and RT-AX58U (3004 RMerlin codebase) did not work well, in respect of propagating the various bands to nodes (and how many get propogated). A discussion of those limitations is detailed here.

REVISED CONFIGURATION

My aim was to remain as close to the stock settings (not stock FW) as possible and deviate from it insofar as it was necessary to achieve stable, robust IoT device connectivity, for IoT devices which are almost exclusievly "fixed" location. This is important bcause they do not (and should not "roam" to find better Wifi at a different AiMesh Node.

Note that there are many discussions on the merits of stock FW on Nodes vs RMerlin FW on Nodes. I will not argue this point here, but the latest I have seen from RMerlin is that it makes no difference and that reccommendation to use stock on AiMesh Nodes was based on information which is now outdated. I am using stock on the RT-AX86U Pro Nodes and RMerlin on the RT-AX58U Node. I will probably (next visit, next year) put RMerlin on all Nodes as I like the ability to be able to run amtm and the occasional light script on the Nodes too.

What I discovered (and this is where @Tech9 is oh so right ) is that AiMesh does not allow different TX Transmit power per node. You can reduce the main TX (not sure if the also reduces the nodes) but I do not believe you can equalise them. What this menas is that oftentimes a weak Wifi IoT device (and I have maybe 30-35 Shelly IoT devices at this location, with weak Wifi) 'migrate' to a further away Router and latch on to that. This does not make sense, but it is only doing what it is told to do, so you cannot blame the device. If you try to "bind" the device to the closest Node, sometimes it works but most often the system simply tells you it is too weak and goes off to the (more powerful) Main Router.

Whilst Shelly devices have a fallback Wifi, I decided to delete this second Wifi from all the Shelly devices as I found it does not work as intended, but mostly because I have scripts on a few of them, which rely on fixed IP addresses on the IoT subnet. I found that even when they fell off the Primary Shelly Wifi SSID, they often did not fall back to the secodnary Wifi and even sometimes got struck in limbo between them. So my rationale here became make the Wifi good enough that they always get on and stay on the desired Wifi SSID.

REVISED SETUP WITH SMART CONNECT (ENABLED)

By as close as possible to stock settings (stated above) I mean Smart Connect enabled (I do not like separate SSIDs and in any case, I limited the IoT GNP network to 2.4Ghz, WPA2). This was my starting point.

After that what I did was this:

• Selected, under AiMesh System, Settings, "Ethernet Backaul Mode" (Default is DISABLED).
  
  I appreciate many say leave it off and just put Backhaul Connection Priorty on Auto (it is), but I have the luxury (many do not) of Ethernet Backhaul, so if I can free up Wifi bandwith for 2.4Ghz and 5Ghz, for my Main and two Guest Networks (Guest and IoT), all the better, IMO. Simply put, this works for me. YMMV (or your bandwidth i.e. YBMV). At this point I am not too concerned about the nodes disconnecting and losing all clients if Ethernet goes down, they should migrate to the main or another node (because that is what they did before). I will watch it.
  
  
• Selected, under Wireless, General, 2.4Ghz Control Channel 11 (Default is AUTO).
  
  I did this as it a less crowded channel in my area, but still one of the non-overlapping ones (from Channels 1, 6, 11).
  
  
• Selected, under Wireless, General, Smart Connect Rule Hyperlink, the following Trigger and STA changes:
  
  Smart Connect RSSI Thresholds
  
  Upper Table = Steering Trigger Condition
  
  2.4GHz: -70dBm from the -62 dBm (default) - Considers devices with weaker signals for steering (Shellys at -75 to -88 dBm need help finding closer nodes)
  
  More negative (e.g., -75): Considers weaker devices for steering
  Less negative (e.g., -55): Only considers very strong devices
  
  5GHz: -68 dBm from the -82dBm default - More aggressive steering for mobile devices (phones/tablets roaming between rooms)
  
  Lower Table = STA Selection Policy (minimum acceptable signal for target AP):
  
  2.4GHz: -70 dBM from the -62 dBm (default) - Accepts weaker target APs as valid (nodes have lower Tx power than main)
  
  More negative (e.g. -75): Accepts weaker target APs
  Less negative (e.g. -55): Devices only move to very strong APs
  
  5GHz: -82 dBm (Default, unchanged) - Keep low orginal threshold - accept any reasonable 5GHz AP
  
  The reasons for this are (as I understand it) due to the GT-AX6000 main router having much higher TX power than RT-AX86U Pro nodes → devices see strong signal from main router everywhere → all devices connect to the main router even when physically closer to nodes. Solution: Make thresholds more aggressive so Smart Connect considers more devices for steering to closer nodes. It works!
  
  
• Selected, under Wireless, Professional, 2.4Ghz, Roaming Assistant Set to Disable (5Ghz is unchanged on AUTO (-70dBm), which is the default for Both).
  
  I did this as it with Smart Connect on (-yy dBM Steering) AND Roaming Assist on (with a -xx dBm value), when a device's signal drops below the xx threshold, it forcibly kicks the device off (i.e. my disconnects issue).
  
  It then forces the device to reconnect and find a better AP (i.e. it "Assists" by going hunting for a stronger signal, but that might be well away from the device).
  So why Disable Roaming Assistant on 2.4GHz? Well, I already have Smart Connect doing the "steering" of that device at -yy dBm, so if Roaming Assistant is ALSO enabled at -xx dBm, you get:
  
  -yy dBm: Smart Connect suggests roaming (gentle)
  -xx dBm: Roaming Assistant force-disconnects (aggressive); I do not want that kind of "Roaming Assistance", the IoTs are stationary devices, I want them connected to the closest node and stay connected, done.
  
  This now works well, IoT devices staying connected to Nodes on the 2.4Ghz band and 2.4GHz/5Ghz mainly iOS Guest devices or Windows laptops with good strong, fast signals at each closest Node. Happy!
  
  
  
  
  
  
  

 

[Tech9]

@jksmurf, I would never organize such mix-and-match consumer system for a remote site with high reliability requirements. In my parents' house thousands of kilometers away I had Cisco router with integrated PoE switch and Cisco access points with PoE for >10 years without single hiccup. Two ISP lines to ensure they have Internet, the router had excellent Dual WAN management. It wasn't cheap, over $1000 at the time of purchase. It's worth it though. Too bad Cisco discontinued the product line and there was no replacement. Otherwise next similar Cisco setup was coming in without even thinking for a second. Now I have UniFi there, hopefully it's as reliable as Cisco.

 

[jksmurf]

@jksmurf, I would never organize such mix-and-match consumer system for a remote site with high reliability requirements. In my parents' house thousands of kilometers away I had Cisco router with integrated PoE switch and Cisco access points with PoE for >10 years without single hiccup. Two ISP lines to ensure they have Internet, the router had excellent Dual WAN management. It wasn't cheap, over $1000 at the time of purchase. It's worth it though. Too bad Cisco discontinued the product line and there was no replacement. Otherwise next similar Cisco setup was coming in without even thinking for a second. Now I have UniFi there, hopefully it's as reliable as Cisco.

Understood but weo of the RT-AX58U on 3004 and a TP Link switch specifically to handle subnets, it is (should be) specifically designed to work as an integrated system.

All 3 VLAN capable, GNP Capable, 3006.102 codebase routers. Yes the GT-AX6000 has higher Tx power than the two RT-AX86U Pro nodes, but this is exactly why I needed to trigger and steer devices to the best node; and it works.

It is not however just plug and play, leave it all on auto and smart-connect setup that Asus might have you believe; that, AFAIK is a hiding to nothing.